Re: libtool and /usr/local/lib

[Jacob Meuser]

On Mon, Sep 27, 2004 at 01:38:07PM -0500, Bob Friesenhahn wrote:
> On Mon, 27 Sep 2004, Geoff wrote:
> >>
> >>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.
> >
> >And some seem either not to hardcode the path, or use a
> >mixture of paths that are hard coded and some that are not,
> >such as my librpm.la
> >
> >dependency_libs=' -L/usr/lib /usr/lib/librpmdb.la
> >-L/usr/local/lib /usr/lib/librpmio.la -lrt -lpthread -lbz2
> >/usr/lib/libpopt.la'
> >
> >Anyway, I am getting out of my depth here.
> 
> Hard-coding the path to the .la file ensures that the "correct" files 
> are used and is faster than scanning through a linker search path. 
> Libtool assumes that the developer's environment is sane and 
> consistent.

IMO, libtool should not limit capability to "protect" people.
Sorry, but if you don't know that ordering of -L affects which
lib is chosen (assuming that there is more than one), then too bad.
Go read your manual.  And once you know how tht works, then you can
actually use that to your advantage, when the need arises.

To me, this is like the problem M$ products, assuming the user is
unintelligent and unknowledgable.

> The best fix is for package maintainers to put their heads together so 
> that libraries shared by multiple packages are placed in consistent 
> locations.  Without consistency, results are indeterminant, even if 
> the link is an apparent success.

That's not what I'm talking about.  I'm talking about the user
deciding to install binaries where they want them.  The package
maintainer really has no control of that, even though some (most?)
binary package tools explicitly allow such an action.

-- 
<address@hidden>