Re: g++ and -nostdlib

[Peter Rosin]

[dropping address@hidden

On 2013-11-12 12:24, Peter Rosin wrote:
> [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?

And why do I not find any such info in the .la file for the attached test
case?

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

I have been toying with the attached test case, but as predicted I'm getting
nowhere. I can't seem to get anything interesting recorded in the libcpp.la
file (such as the needed library dependencies, e.g. -lstdc++). Since no
library dependencies are recorded in libcpp.la, I fail to see how killing
the -nostdlib dance is going to change anything at all for this test case.

On Cygwin, I have tried configuring libtool with

.../configure GCC="gcc -static-libgcc" CFLAGS=-O0 \
GXX="g++ -static-libgcc -static-libstdc++" CXXFLAGS=-O0

but still no dice. It just works whatever I try.

Except one thing that reliably causes the test to fail, and that is to
only build a static version of the module. But then it fails during linking
of the program both with and without the -nostdlib dance during C++ linking
(since nothing interesting is recorded in the libcpp.la file, I presume).

Suggestions on what's needed to reveal what the actual pattern is that makes
the -nostdlib dance help is still welcome.

Cheers,
Peter

0001-tests-check-mixing-C-program-with-CXX-module.patch
Description: Text Data