GNU bug report logs - #8557
libtool run against newly built libraries fails in setarch 'i686'

Previous Next

Full log

View this message in rfc822 format

From: Jason Vas Dias <jason.vas.dias <at> gmail.com>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: 8557 <at> debbugs.gnu.org
Subject: bug#8557: libtool must not depend on existence of system '/usr/lib*/*.la' files
Date: Wed, 27 Apr 2011 01:22:58 +0100

On Tuesday 26 April 2011 17:56:22 Mike Frysinger wrote:
> On Tue, Apr 26, 2011 at 08:38, Jason Vas Dias wrote:
> > My 32-bit C++ libtool builds were failing because libtool incorrectly accessed
> >   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++v3.la ,
> > which gcc installs for its 64-bit environment, NOT
> >   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libstdc++v3.la ,
> > which gcc installs for its 64-bit environment.
> 
> you mean which gcc installs for its 32-bit env
> 
> > And I try to rebuild the 32-bit package from scratch, and it fails because libtool can
> > find no system 'libstdc++v3.la' file.
> 
> most likely not a bug in libtool.  something (probably a .la file) has
> encoded a reference to the libstdc++ .la file.  find that something
> and fix it.
> -mike
> 
> Hi Mike - thanks for responding ! 
> Actually , I can't find ANY references to 'stdc++*.la' under any /{,usr/}lib*/ directory :
> [ root <at> jvdspc:/ 00:23:51 1256:750 ]
> $ cd /;   find lib32/ lib64/ usr/lib32/ usr/lib64/ -name '*.la' -a -type f | while read f; do egrep -Hn 'stdc\+\+[^.]+\.la' $f; done

OOPS:  SORRY !                                                                                             this should be ^'stdc\+\+[^.]*\.la'

So yes, those stdc++*.la references were bogus, sorry !

But my questions remain :

> [ root <at> jvdspc:/ 00:24:24 1257:751 ]
> 
> But I see code in libtool that is looking translating a reference to  '-lstdc++'  into looking for (any dir in $sys_lib_search_path_spec)/stdc++.la  .
> 
> 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 ?
>
>If I change this line of libtool (GNU libtool 1.3332 2011-04-10) 2.4.1a 's
> installed /usr/bin/libtool :
>
># Compile-time system search path for libraries.
>sys_lib_search_path_spec="/usr/lib64/gcc/x86_64-pc-linux-gnu/lib64
> /usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib "
>
>TO:
># Compile-time system search path for libraries.
>sys_lib_search_path_spec="$(${CC:-gcc} $CFLAGS -print-search-dirs |sed -n
> '/^libraries:/{s/^libraries[:=\ \       ]*//;s/:/ /g;p}')"
>
>and remove wherever it says "-nostdlibs \$predep_objects"  or
> "\$postdep_objects" from link command lines, then everything is hunky-dory
> !
>
>There is no bogus dependencies on any stdc++*.la generated either by the gtk
> build of bug #8557 either by that version, nor is there any glibc bug
> #12454 triggered by a poppler build as in bug #8537 .
>
>It seems to me that libtool is doing too much second-guessing of gcc's
> correct defaults on the Linux platform ; ie. specifying defaults for gcc
> (sometimes incorrectly!) that gcc would in any case get correct all on its
> own.

Please, Mike, why is libtool not using some form of dynamic setting of $sys_lib_search_path_spec from $CC and $CFLAGS ???

Previous Next

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