bug#8537: libtool must not depend on existence of system '/usr/lib*/*.la' files

[Mike Frysinger]

On Wed, Apr 27, 2011 at 19:55, Jason Vas Dias wrote:
> Then I looked at the /usr/bin/libtool to see what it was doing that could 
> shed light on these bugs;
> that's the only program that libtool installs from its source that one can 
> test , and is mentioned
> in the documentation - many of the documentation examples would fail if the 
> $CFLAGS used in
> them selects a different $sys_lib_search_path , because the /usr/bin/libtool 
> program would use
> the wrong $sys_lib_search_path_spec setting .

yes, and that is currently expected behavior

> Perhaps a really nice new feature for libtool would be some option to make 
> all libtool scripts
> not install any .la files in /{,lib,usr/lib}*/ and to ignore any .la files 
> found there ?

i dont think that'd be useful

> Or at least, when some .la is not found, to print which .la it was sourcing 
> that caused it to
> look for the missing .la ? ( Some ".la backtrace" feature ? )

if you run with --debug, you can grep for .la files in the output

although it's usually pretty easy to just look at the output and
guess.  if libtool is invoked with -lfoo and the verbose output from
libtool says /usr/lib/libfoo.so, it most likely hit an .la file for
it.

> And why if the $CFLAGS makes gcc look in /usr/lib32 first , and never look in 
> /usr/lib64, should ANY
> libtool script be looking for a 32-bit .la or anything  in /usr/lib64/ ?

hardcoding 64bit:/usr/lib64 and 32bit:/usr/lib32 doesnt make sense ...
these are arbitrary conventions picked by gcc specifically for
i686/x86_64 linux targets.  libtool has no concept of multilib today
which is why you have to configure libtool specifically for each
build.

> I thought perhaps it was because those compiled scripts somehow inherited the
> sys_lib_search_path_spec setting behaviour from the /usr/bin/libtool script . 
> Why
> install /usr/bin/libtool if it is not meant to be used for anything but gcc ?

ultimately this decision is up to your distro provider, but installing
the default libtool is useful for building/linking with the
default/native target.  there are also (poorly written) packages that
invoke `libtool` from $PATH instead of bundling its own local version.

> And I'd still like an answer to the basic question "why is libtool doing so 
> much on Linux
> when gcc gets it right on its own" ?

your view of libtool is clouded by your very narrow focus on recent
versions of gcc/Linux targets.  libtool scales to many many more
targets, and its complex system is designed to handle severly
deficient targets.  albeit at the cost of being more complex than
necessary for some modern/sane targets.
-mike