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 linkjust 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
>From 56080c9349ae56fcac6e7bf7f6081dfa48a7fc67 Mon Sep 17 00:00:00 2001
From: Peter Rosin
Date: Mon, 11 Nov 2013 09:48:23 +0100
Subject: [PATCH] libtool: Do not use -nostdlib when linking with g++.
Fixes part of bug#15646 and Debian bug 468555.
* m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [g++]
: Drop -nostdlib, $predep_objects and
$postdep_objects.
(_LT_LANG_CXX_CONFIG) [g++]: Do not look for hidden library
dependencies.
* NEWS: Update.
---
NEWS |6 ++
m4/libtool.m4 | 34 ++
2 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/NEWS b/NEWS
index 0c85812..5717385 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ NEWS - list of user-visible changes between releases of GNU Libtool
* Noteworthy changes in release ?.? (-??-??) [?]
+** Important incompatible changes:
+
+ - When linking shared libraries with g++, trust the compiler driver to
+interface correctly with the linker. I.e., drop the -nostdlib
+option in this case. Fixes point 2 (and perhaps 3) in bug#15646, as
+well as Debian bug 468555.
* Noteworthy changes in release 2.4.2.418 (2013-10-27) [alpha]
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4bc6b22..e34e021 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -6046,8 +6046,8 @@ if test yes != "$_lt_caught_CXX_error"; then
# Check if GNU C++ uses GNU ld as the underlying linker, since the
# archiving commands below assume that GNU ld is being used.
if test yes = "$with_gnu_ld"; then
-_LT_TAGVAR(archive_cmds, $1)='$CC $pic_flag -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags $wl
