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

[Jason Vas Dias]

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 :
> [ address@hidden:/ 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 :

> [ address@hidden:/ 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 ???