[Mingw-notify] [ mingw-Bugs-2836185 ] [gcc-4.4.0] Dll fails to build with shared libstdc++

[SourceForge.net <no...@so...>]

Bugs item #2836185, was opened at 2009-08-12 08:17
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2836185&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
>Group: Known bugs
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Peter Hurley (peterjhurley)
>Assigned to: Aaron W. LaFramboise (aaronwl)
Summary: [gcc-4.4.0] Dll fails to build with shared libstdc++

Initial Comment:
The following code fails to link uisng gcc-4.4.0-mingw with undefined references:

/*
 * dllmain.cpp
 */

#include <exception>

void my_baaaaad_function()
{
	throw std::exception();
}

Compiled/attempted link with:

g++ -D_GLIBCXX_DLL -O0 -g3 -Wall -c -odllmain.o ..\dllmain.cpp 
g++ -shared-libgcc -shared -otestdll.dll dllmain.o -lstdc++_s

The problem appears to be that the system headers <exception>,<typeinfo> and <new> use _GLIBCXX_DLL to decorate the exception classes.  However those classes are not included in the libstdc++_s.a archive (nor in the libstdc++-6.dll).

A workaround is to remove the decorations from those system headers.

-- Build environment --
Windows XP Pro SP3
intel harpertown
gcc-4.4.0-mingw
binutils-2.19.1
w32api-3.13
mingw32-make-3.81

----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2009-08-13 08:31

Message:
Thank you for the detailed information.

----------------------------------------------------------------------

Comment By: Peter Hurley (peterjhurley)
Date: 2009-08-12 16:50

Message:
There's some confusion here.

First, compiling the headers <exception>,<new> and <typeinfo> with
_GLIBCXX_DLL defined means that the following classes will be decorated
with __attribute__((dllimport)):
     exception
     bad_exception
     bad_alloc
     bad_cast
     bad_typeid

So, e.g., a reference to exception::~exception will be emitted as a
reference to _imp___ZNSt9exceptionD1Ev (rather than __ZNSt9exceptionD1Ev).

This is the real bug --> No amount of fiddling with which library to link
to first will make that _imp___ZNSt9exceptionD1Ev symbol appear because it
does not exist in any 4.4.0 library, shared or not. (I suspect that
something's broken in the build of libsupc++ where those headers live).

Second, that the g++ driver is not forcing the shared c++ library (with
-shared -shared_libgcc) is a separate bug.  Fixing it will not fix the
first bug above.

Third, since the shared c++ library is not a complete implementation, both
static and shared libraries must co-exist, even with the same executable. 
That's also going to give rise to multiple definitions, requiring the use
of --allow-multiple-definition for a workaround.  (An example of this is
runtime_error - if you throw runtime_error from a source file that's
compiled with _GLIBCXX_DLL, you're going to need to use
--allow-multiple-definition to get it to link) But this is also a separate
issue and,again, not directly related to the first bug.

PS - I did use --verbose (see earlier comment + attached link trace).
That's how I knew that -lstdc+_s was required...

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2009-08-12 15:48

Message:
So the likelihood that you are getting both the static and shared libraries
are great and the bug becomes the SPEC file itself.  Pass the verbose
switch to the linker to determine if this is indeed the case.

----------------------------------------------------------------------

Comment By: Peter Hurley (peterjhurley)
Date: 2009-08-12 12:36

Message:
earnie said >> It should be included by the spec file for g++ when
-shared-libgcc-shared is given.

Right -- but it doesn't.  In the recently attached text file of the trace
output from ld, you can see that libstdc++.a is what is bound, not
libstdc++_s.a

(The command used to output that trace is the 1st line in the file but for
completeness sake:
g++ -shared-libgcc -Xlinker --trace -Xlinker --verbose -shared
-Wl,--out-implib=testdll.a -otestdll.dll dllmain.o

I hadn't reported that the driver didn't actually force the shared c++
library because I don't want to offend people that are doing a good job by
posting up a bunch of bugs all at once.  (Heads up though - there's also a
multiple definition problem with some of the classes that have been moved
to the shared library because they're in both libraries - eg.
runtime_error).

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2009-08-12 11:34

Message:
<quote>g++ -shared-libgcc -shared -otestdll.dll dllmain.o
-lstdc++_s</quote>

Why do you specify the -lstdc++_s on the command line?  It should be
included by the spec file for g++ when -shared-libgcc-shared is given.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2836185&group_id=2435