Re: libtool and /usr/local/lib

[Bob Friesenhahn]

On Mon, 27 Sep 2004, Jacob Meuser wrote:
> > 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.

Unknowledgable is not the same as unintelligent.  For example, the 
user was not aware that there was a libxml2 under the /usr/X11R6 tree 
as well as under the /usr/lib tree.  LibMagick was apparently built 
and tested with the libxml2 under /usr/X11R6.  Are the already-built 
binaries compatible with a different libxml2 install?  Who knows?

Libxml2 may be configured different ways.  One build may support 
multiple threads while the other does not.  Maybe the two builds are 
not ABI compatible?

Given that using a different library may cause problems, perhaps it is 
a good thing that the .la files remember where they are?

> 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.

Even though a binary package tool may allow installing a package 
anywhere, many packages will only work properly when installed in a 
particular directory.  This is due to including embedded paths so 
they can find configuration files.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen