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 [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
