[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