[plt-dev] drscheme executable linked to old libs

From: Eli Barzilay (eli at barzilay.org)
Date: Tue Jun 16 17:08:06 EDT 2009

On Jun 16, Marijn Schouten (hkBst) wrote:
> 
> Eli Barzilay wrote:
> > On Jun 15, Marijn Schouten (hkBst) wrote:
> >> I'm using plt-scheme-4.2.
> >> When starting drscheme, I get:
> >>
> >> $ drscheme
> >> /usr/bin/mred: error while loading shared libraries:
> >> libmzscheme3m-4.1.5.so: cannot open shared object file: No such
> >> file or directory
> >>
> >> 4.1.5 is the version I had installed while upgrading to 4.2. I
> >> had the same problem when upgrading to 4.1.5 from 4.1.4. The
> >> workaround is to install the upgrade twice. I don't run drscheme
> >> very often, so I don't know how far back the issue goes.
> >>
> >> I thought this was the same issue as the path issue reported wrt
> >> mac builds, but it remains unfixed on linux.
> > 
> > If this is due to that problem (using the mac ports thing), then
> > it is likely to continue being a problem in this way because you
> > have some stuff at /usr that should really be inside the PLT tree.
> > In addition, I don't know if they fixed their build routine, or
> > how.
> 
> Well, the old installed version is at prefix /usr. The new version
> is compiled in a staging area (DESTDIR). The compilation process
> should use its own libraries instead of using the old installed
> ones.

It should, but there are some issues with things in /usr that have
precedence over things in the local build directory -- so AFAICT (from
second-hand experience), the best way to deal with this is to manually
remove all the bogus files in /usr.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!


Posted on the dev mailing list.