[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool and /usr/local/lib

From: Jacob Meuser
Subject: Re: libtool and /usr/local/lib
Date: Mon, 27 Sep 2004 11:06:43 -0701
User-agent: Mutt/1.4.2i

On Mon, Sep 27, 2004 at 10:28:14AM +0100, Geoff wrote:
> On Mon, 27 Sep 2004 00:58:28 -0700
> Jacob Meuser <address@hidden> wrote:
> <snip>
> > 
> > probably some .la file is requesting /usr/lib/
> > as a dependency, my guess would be  you can
> > probably get away with editing the problem file(s) to
> > reflect the correct path to
> > 
> > to find the offending .la file(s), do something like the
> > following:
> > 
> > $ for i in /usr/lib/lib*.la /usr/local/lib/lib*.la ; do \
> > > grep -l '/usr/lib/libxml2\.la' $i ; done
> Thanks for the quick and helpful reply Jacob.  Your little
> script throws up 32 .la files which depend on
> /usr/lib/libxml2. is not one of them, but many
> gnome libraries are, and, although I don't run
> gnome, I do have several applications which use the
> libraries.  Gnome was certainly implicated in the failure of
> xine-libs to compile.
> I guess it is easier to make the symlinks, or reinstall
> libxml2 in /usr/lib, than to edit all those files.

or just change the above grep command to a sed command.

> > it's best though, when updating/reinstalling a package, to
> > first completely remove all dependent packages, then
> > reinstall them.
> That is something I have wondered about before, but I have
> run linux now for 5 years (including Linux from Scratch),
> and I don't recall ever encountering a problem like this
> one.  I suppose I have just been lucky.  Further, my 32
> dependent libraries show that finding and recompiling all
> dependencies in any given case could be a major enterprise.

IMO, such hardcoding of library location should be discouraged.
why does libtool add the full path of the .la file, instead of
-L<path> -l<lib>?  even if the <path> is wrong, there are other
ways to get libtool or the linker to find the .la file or at
least the library.

here's a situation to consider ... binary packages that are
built with the libraries in /usr/local/lib, but installed
into /opt/package/lib.  the hardcoded paths bork this type
of installation (same with hardcoded paths in shared libs).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]