[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: Thu, 28 Apr 2011 00:55:33 +0100
User-agent: KMail/1.12.4 (Linux/; KDE/4.3.4; x86_64; svn-1073138; 2010-01-11)

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 SPECIFYING -nostdlibs  -nostdlib \$predep_objects AND 
> 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 

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

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]