Description of problem: When trying to build a DLL (I think it'd be the same thing with an EXE though) with the -static-libgcc flag using the mingw-w64 cross-compiler in the Fedora 17 repository, I ran into symbol conflicts between libgcc_eh.a and libgcc_s.a: there are errors about multiple definitions of several "_Unwind_*" symbols. Unfortunately, the code uses exceptions, so -fno-exceptions is not an option. Version-Release number of selected component (if applicable): mingw64-gcc-4.7.0-2.fc17 mingw64-gcc-4.7.2-2.fc17 (Both versions fail with the same error.) How reproducible: Always. Steps to Reproduce: 1. Try to link a MinGW64 C++ EXE or DLL which uses exceptions with -static-libgcc. (In my case, it was the Java bindings for Ipopt.) Actual results: Multiple definitions of unwinding-related symbols. Expected results: Links successfully. Additional info: http://tdm-gcc.tdragon.net/development says that TDM-GCC has a local patch for what appears to be this same issue: > Includes a patch which reintegrates the code from libgcc_eh.a into libgcc.a > and the libgcc DLL. As long as the shared memory region is used to handle > exceptions, this library is unnecessary, and it causes multiple definition > errors for the symbols in it because it hasn't been added to binutils' > exception libraries yet. Therefore I am asking whether we can get that fix (or some other fix for this bug) into the Fedora mingw64-gcc packaging.
I tested it with some small C++ code myself and I don't get this conflict. Could you please provide some small sample-code, which is able to reproduce you problem? Additionally provide please the command-line for this testcase. Btw as work-a-round you might want to use linker option --allow-multiple-definition. At least it seems to me as being worth a test.
Do you happen to have a .src.rpm of the package which is showing this failure (or another easy to reproduce testcase)? I just looked at the tdm-gcc sourceforge site and I found a patch called gcc/libgcceh.patch in http://sourceforge.net/projects/tdm-gcc/files/Sources/TDM%20Sources/gcc-4.7.1-tdmsrc-1.zip/download The readme mentions the following comment about this patch: Reintegrate libgcc_eh into libgcc. Is this the patch you're talking about? Did you already try to apply it manually to our mingw-gcc package?
The following patch to gcc's gcc/config/i386/ directory might solve this reported issue. Could you give it a try? Regards, Kai Index: mingw32.h =================================================================== --- mingw32.h (Revision 193669) +++ mingw32.h (Arbeitskopie) @@ -121,15 +121,24 @@ /* Include in the mingw32 libraries with libgcc */ #ifdef ENABLE_SHARED_LIBGCC -#define SHARED_LIBGCC_SPEC "%{shared-libgcc:-lgcc_s} %{!shared-libgcc:-lgcc_eh}" +#define SHARED_LIBGCC_SPEC " \ + %{static|static-libgcc:-lgcc -lgcc_eh} \ + %{!static: \ + %{!static-libgcc: \ + %{!shared: \ + %{!shared-libgcc:-lgcc -lgcc_eh} \ + %{shared-libgcc:-lgcc_s -lgcc} \ + } \ + %{shared:-lgcc_s -lgcc} \ + } \ + } " #else -#define SHARED_LIBGCC_SPEC /*empty*/ +#define SHARED_LIBGCC_SPEC " -lgcc " #endif #undef REAL_LIBGCC_SPEC #define REAL_LIBGCC_SPEC \ "%{mthreads:-lmingwthrd} -lmingw32 \ "SHARED_LIBGCC_SPEC" \ - -lgcc \ -lmoldname -lmingwex -lmsvcrt" #undef STARTFILE_SPEC
So, after several build attempts with and without the patch, I came to the following conclusion: Basically, Ipopt copies the -l flags used to link LAPACK and MUMPS and wants to reuse them, which is quite silly in the case of libgcc. :-/ The fix is to export LDFLAGS=-static-libgcc when building all of Ipopt. When I do that, it builds successfully with mingw64-gcc-4.7.2-2.fc17, so it looks like no changes to the toolchain are needed.
(And it behaves exactly the same even with the patch from comment #3 added.)