#1332 [gcc-4.4.0] Dll fails to build with shared libstdc++

[Peter Hurley]

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

[Earnie Boyd]

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

[Peter Hurley]

Trace output from ld

[Peter Hurley]

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

[Earnie Boyd]

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.

[Peter Hurley]

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

[Earnie Boyd]

Thank you for the detailed information.