Re: g++ and -nostdlib

[Peter Rosin]

[re-adding address@hidden

On 2013-11-11 16:10, Bob Friesenhahn wrote:
> 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.

Right, I wasn't really serious.

>> 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.

Even if GCC did report dependent libs correctly (for the libtool version
of correctly), libtool would have a difficult time replicating what libs
to actually apply if one project builds a number of libraries/programs
with different GCC options. It's a bit fragile by design.

>> 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.

And why wouldn't the standard library be picked up again by the compiler
driver when linking the dependent executable?

> 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.

I don't understand why it is necessary to relist dependencies that
the compiler driver is going to find anyway. Why does libtool need
this degree of control?

>> 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.

Ok, so this test sometimes fails even if libtool tries to be clever.
Maybe it fails because libtool is too clever? It would be interesting
to know if the test continues to fail if libtool just trusts the
compiler driver (i.e. with the patch applied). I can't tell, because
the test works both with and without the patch for me.

> 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.

I didn't notice that libtool@ was dropped by Chuck. So, I'm switching
to that list instead. Please drop libtool-patches@ next time.

Anyway, when I started this thread, my main interest was to understand
*why* libtool does the -nostdlib dance. But as I'm not personally
affected by it, I'm not really pushing for my patch, it is mainly there
to trigger discussion. What I would like to see is some test cases that
actually fails when libtool simply trusts GCC to DTRT. Currently the
test suite is clean with my patch, at least on Cygwin. If we have some
test cases we know what is sacrificed if -nostdlib is dropped.

If we can't construct a valid test case that works with -nostdlib, but
fails without it, that would be quite telling though...

So, can someone conjure up such a test case? I can't, I'd be fumbling and
wouldn't know where to start.

Cheers,
Peter