[dropping libtool-patches@] On 2013-11-12 12:24, Peter Rosin wrote: > [re-adding libtool@] > > 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
>From 02dce94738c3e8f2670d9997bf9e144ade8a7691 Mon Sep 17 00:00:00 2001 From: Peter Rosin <p...@lysator.liu.se> Date: Fri, 6 Dec 2013 09:43:26 +0100 Subject: [PATCH] tests: check mixing C program with C++ module. --- Makefile.am | 1 + tests/c-cpp.at | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 76 insertions(+), 0 deletions(-) create mode 100755 tests/c-cpp.at diff --git a/Makefile.am b/Makefile.am index fe269ed..1d76d63 100644 --- a/Makefile.am +++ b/Makefile.am @@ -668,6 +668,7 @@ TESTSUITE_AT = tests/testsuite.at \ tests/template.at \ tests/ctor.at \ tests/exceptions.at \ + tests/c-cpp.at \ tests/early-libtool.at \ tests/no-executables.at \ tests/deplibs-ident.at \ diff --git a/tests/c-cpp.at b/tests/c-cpp.at new file mode 100755 index 0000000..825c55a --- /dev/null +++ b/tests/c-cpp.at @@ -0,0 +1,75 @@ +# c-cpp.at -- check mixing languages -*- Autotest -*- +# +# Copyright (C) 2013 Free Software Foundation, Inc. +# Written by Peter Rosin +# +# This file is part of GNU Libtool. +# +# GNU Libtool is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# GNU Libtool is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with GNU Libtool; see the file COPYING. If not, a copy +# can be downloaded from http://www.gnu.org/licenses/gpl.html, +# or obtained by writing to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +#### + + +AT_SETUP([mixing C and C++]) +LT_AT_TAG([CXX]) +AT_KEYWORDS([libtool]) + +AT_DATA(libcpp.cpp, +[[ +#include <iostream> + +using namespace std; + +extern "C" int +hello(void) +{ + cout << "hello" << endl; + return 0; +} +]]) + +AT_DATA(cprog.c, +[[ +int hello(void); + +int +main(void) +{ + hello(); + return 0; +} +]]) + +LT_AT_HOST_DATA([expout], +[[hello +]]) + +AT_CHECK([$LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS $CXXFLAGS \ + -c libcpp.cpp -o libcpp.lo], [0], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --tag=CC --mode=compile $CC $CPPFLAGS \ + -c cprog.c -o cprog.lo], [0], [ignore], [ignore]) + +AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS \ + -no-undefined -module -rpath /somewhere \ + -o libcpp.la libcpp.lo], + [0], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --tag=CC --mode=link $CC $CFLAGS $LDFLAGS \ + -o cprog$EXEEXT cprog.lo -dlpreopen libcpp.la], + [0], [ignore], [ignore]) + +LT_AT_NOINST_EXEC_CHECK([./cprog$EXEEXT], [-dlopen libcpp.la], [], [expout]) + +AT_CLEANUP -- 1.7.9
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
