Re: g++ and -nostdlib

[Peter Rosin]

On 2013-11-08 20:07, Charles Wilson wrote:
> On 11/8/2013 1:49 PM, Bob Friesenhahn wrote:
>> Isn't it because libtool wants to control the order of the linking and
>> assure that all dependencies (including static) are tracked/known and
>> applied at the correct times?  It wants to assure that static
>> dependencies are linked into the dependent program rather than into some
>> dependent shared library (and thus causing a problem).
>>
>> It was common (and perhaps still is) for the GNU C++ library to be
>> delivered as a static library for Windows/MinGW because C++ exceptions
>> were not handled properly when thrown by DLLs.
>>
>> 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 :-)

>> First libtool tries to take away all of the libraries which would be
>> added automatically and then it applies the libraries that GCC says it
>> would use at the correct time.
>
> One of my wishlist roundtuit items is to special-case this behavior
> for libtool + GNU toolchains. For that combo, instead of the
> procedure Bob outlines, and then using $LD to link....just use the
> compiler driver (e.g. g++, or gfortran, or gcc) to link, WITHOUT
> -nostdlib [1]. We're already passing the ABI-modifying -m and -f
> flags anyway, and it would really REALLY simplify libtool's logic...
>
> [1] unless of course the end user put -nostdlib in $LDFLAGS or something.

Hmmm, I don't get it. For me (on Cygwin, but reading the code suggests that
the following holds for all hosts) libtool already uses the compiler driver
to link C++ for GNU toolchains. The only "abnormal" thing I see is the
-nostdlib dance.

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.

I also had a closer look at the result of my first patch and have attached
a 2nd attempt that zaps more cruft (predep and postdep libraries) from the
linking stage. This version should be close to the above wishlist item
mentioned by Chuck (even if the complicated logic isn't actually removed
by my small change, it's just bypassed for g++).

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

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

Is that it?

Cheers,
Peter

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460

0001-libtool-Do-not-use-nostdlib-when-linking-with-g.patch
Description: Text Data