Re: g++ and -nostdlib

[Bob Friesenhahn]

On Mon, 11 Nov 2013, Peter Rosin wrote:
> > > Quite a lot of effort went into making this work the way it currently does.
>
> I realize that, but if it really works or not is a different question :-)

Yes, of course. It is obviously primarily "working" as demonstrated by 
the massive amount of software linked for years and years using 
libtool.

> I.e., as far as I can tell, $LD is not used for linking. $CXX is used, with
> -nostdlib and some manually detected libs/objects, which end up wrong if
> different flags (such as -pthread) are used when digging and actually linking.

Yes, GCC has known bugs with reporting the libraries which would 
actually be used based on proposed arguments.  It must be the case 
that GCC maintainers don't consider this to be a bug since GCC has not 
changed its behavior.

> Googling a bit more turned up this old quote from Ralf [1] on this subject:
>
>   BTW, I believe libtool does the -nostdlib stuff because, at least in the past,
>   not using it could cause situations where later libstdc++ would not be found
>   automatically.  I think at least for dlopen'ed modules depending on C++
>   libraries this is still the case (completely untested).
>
> That was 8 years ago, even then it appears noone really knew why -nostdlib
> is used (which is interesting in itself).

As far as I am aware, the issue is primarily due to some C++ standard 
libraries being delivered as static libraries (usually due to C++ 
exceptions problems) and therefore necessitating being linked to the 
dependent executable rather than into a shared library (which may then 
be linked with other shared libraries linked into an executable). 
This magic is done via information cached in the .la files.

Intuiting all the libraries which would be used has been a core tenant 
of libtool given that it attempts to record all the linkage 
dependencies in its .la files.

> So, someone needs to write some test cases that tries to build a library
> with --static-libgcc and then use that in a program w/o --static-libgcc
> (and vice versa), as well as doing some dlopen test with C++ modules to
> try to deduce if the above problem described by Ralf can still be
> reproduced (but his wording suggest that it might be subtle). And lastly we
> might need some test that tries to throw C++ exceptions over DLL boundaries,
> if that isn't already done by tests/exceptions.at...

The tests/exceptions.at tests the ability to catch exceptions thrown 
from a DLL.  It is not uncommon for it to fail with GCC for certain 
targets due to target-specific libtool bugs or GCC compiler bugs. 
Even with this test, it very difficult to tell if the C++ exceptions 
framework is really working.  In my experience, C++ exceptions are 
reliably working with proprietary compilers and sometimes failing with 
GCC.

In my opinion, this topic is significant enough that it should be 
discussed on the general libtool list before any decision to rip out 
the existing special GCC support and treat GCC similar to other 
compilers.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/