GNU bug report logs - #8537
2.4 : triggers libc "nlist > 1" assertion failure from --link in 'setarch i686' environment

Previous Next

Full log

Message #41 received at 8537 <at> debbugs.gnu.org (full text, mbox):

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: 8537 <at> debbugs.gnu.org, 8557 <at> debbugs.gnu.org
Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la'
	files
Date: Thu, 28 Apr 2011 00:55:33 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.