[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8557: libtool must not depend on existence of system '/usr/lib*/*.la
From: |
Jason Vas Dias |
Subject: |
bug#8557: libtool must not depend on existence of system '/usr/lib*/*.la' files |
Date: |
Wed, 27 Apr 2011 01:22:58 +0100 |
User-agent: |
KMail/1.12.4 (Linux/2.6.38.2-jvd; KDE/4.3.4; x86_64; svn-1073138; 2010-01-11) |
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 ???