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

[Jason Vas Dias]

On Wednesday 27 April 2011 04:14:21 you wrote:
> On Tue, Apr 26, 2011 at 19:48, Jason Vas Dias wrote:
> > And my major primary central questions to the whole libtool community 
> > raised in several bug reports (both inadvertently by replying to 
> > 'bug-libtool' and
> > intentionally by creating different bugs - sorry ! - there should be only 
> > two:  #8537 and #8557 ) is :
> >
> > WHY IS LIBTOOL NOT SETTING $sys_lib_search_path_spec DYNAMICALLY BASED ON 
> > $CFLAGS CONTAINING -m$ARCH FLAGS ?
> > WHY IS LIBTOOL SPECIFYING -nostdlibs  -nostdlib \$predep_objects AND 
> > SPECIFYING ALL THE "crt*.o" C-RUNTIME OBJECTS ON A GCC / Linux PLATFORM ?
> 
> drop the caps crap.
> 
> the libtool as found in $PATH targets the toolchain is was configured
> for.  this is why libtool is always packaged/generated with the build
> system in packages that use it ... when you configure/build the
> package for a specific target, the local ./libtool is compiled
> properly for that target.  attempting to use `libtool` for anything
> other than the native gcc really isnt its intended use.
> 
> perhaps in the future this might change as an enhancement, but today,
> it sounds like you're just using it wrong.
> -mike
> 
Hi Mike - thanks for responding ! Sorry, I didn't realize capitals were somehow 
offensive.

RE:  >  the libtool as found in $PATH targets the toolchain is was configured 
for

Yes,  I know this,  but perhaps I made insufficiently clear what led to me 
raising these
bugs was the errors / anomalies observed when just running ./libtool via
"configure" / "autogen.sh" and "make" .
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 .

For bug 8537, this was a combination of poppler's libtool using '-nostdlibs' 
and triggering glibc bug #12454 ,
and for bug 8557, this was mainly because of that stdc++.la being referenced in 
some installed /usr/lib*/*.la file.

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 ? 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 ? )

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/ ?

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 ?

Anyway, installing libtool from the GIT head (requiring upgrade to 
automake-1.11a) seemed to fix the poppler build problem so I guess these
bugs can be closed if noone thinks there are any valid issues raised by them - 
sorry if this is the case.

I'd like to investigate further exactly why the poppler lib32 build specified 
-nostdlibs and triggered glibc bug 12454 with libtool-2.4.1 and automake 1.10.3 
but did not with libtool-2.4.1a and automake-1.11a  .

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" ?
I don't think libtool should be doing things like forcing a library search path 
and -nostdlibs and predep_objects and postdep_objects
on gcc when it doesn't actually need to - ie unless there are exceptional 
circumstances when it is actually required . But this seems to be libtool's 
default behavior.
I'm curious as to what the rational is in forcing -nostdlib builds that 
explicitly specify all the CRT objects when gcc generally does this fine,
except in very rare and exceptional circumstances.

But thanks for your help,
all the best,
Jason