Compiling a Linux -> mingw32-w64 cross-compiler works fine with binutils 2.25.1 but results in a libstdc++6.dll which is less than half the size without debug symbols and crashes on DLL entry point. This problem only occurs for 32-bit target, not for 64-bit target. Compiled GCC 5.3.0 as ../../src/gcc-5.3.0/configure --enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix --disable-nls --enable-shared=libstdc++ --enable-static --enable-fully-dynamic-string --enable-lto --enable-plugin --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw --with-sysroot=/mingw --target=x86_64-w64-mingw32 --enable-targets=all --enable-checking=release --with-gmp=/new-gcc/lib/gmp-5.0.5 --with-mpfr=/new-gcc/lib/mpfr-2.4.2 --with-mpc=/new-gcc/lib/mpc-0.9 --with-isl=/new-gcc/lib/isl-0.12.2 --with-cloog=/new-gcc/lib/cloog-0.18.3 --with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl on Linux (Xubuntu 14.04.3 LTS). All system libraries where compiled with -O3 -mtune=core2 -march=core2 -mstackrealign -fomit-frame-pointer -Wno-maybe-uninitialized -flto -flto-partition=none -fno-builtin-stpcpy Binutils was in both cases (version 2.25.1 and 2.26.51) configured as configure --enable-lto --enable-plugin --disable-nls --target=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --with-sysroot=$PREFIX --prefix=$PREFIX "--with-gmp=/new-gcc/lib/gmp-5.0.5" "--with-mpfr=/new-gcc/lib/${MPFR}" "--with-mpc=/new-gcc/lib/mpc-0.9" "--with-isl=/new-gcc/lib/isl-0.12.2" "--with-cloog=/new-gcc/lib/cloog-0.18.3" "--with-host-libstdcxx=-lstdc++ -lsupc++" --disable-cloog-version-check --enable-cloog-backend=isl I first reported this as GCC bug until I found out that it was a binutils regression by using an older version of binutils. See related GCC bug report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69284
I've encountered a similar problem (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813144 for details), and reverting 0f088b2a9417b1d4ed597849ffa671eba25f5051 fixes it for me... (Not that it's a good long-term solution of course!)
Does adding -Wl,--no-gc-sections act as a workaround ? (Instead of reverting the COFF gc patch, as suggested by Stephen).
-Wl,--no-gc-sections produces a working libstdc++-6.dll for me (with a ld built with the PE/COFF GC patch). I was wondering whether this could be due to a missing section name in pe.sc, but the fact that this is 32-bit specific suggests there's something else going on, right? With both DLLs to hand, how could I go about figuring out what went wrong? (The "bad" DLL has a bunch of undefined symbols.)
Hi Stephen, > -Wl,--no-gc-sections produces a working libstdc++-6.dll for me (with a ld > built with the PE/COFF GC patch). OK, so that is good to know. > I was wondering whether this could be due to a missing section name in > pe.sc, but the fact that this is 32-bit specific suggests there's something > else going on, right? With both DLLs to hand, how could I go about figuring > out what went wrong? (The "bad" DLL has a bunch of undefined symbols.) The undefined symbols are almost certainly the key. They probably should not be undefined. First of all, please try out the patch that I am about to upload. It may be that the problem is that the linker is garbage collecting sections that are really needed, because the linker script failed to mark those sections as KEEP. (You may need to check that the linker script you are using is the one that is fixed by the uploaded patch. Add -Wl,--verbose to the gcc command line to check this). If that does not work then try adding -Wl,--print-gc-sections to the bad DLL creation command line. See what gets thrown away, see if this matches up with the undefined symbols, and try to work out why they are being thrown away. Cheers Nick
Created attachment 9035 [details] Update PE linker script to KEEP more sections
Hi Nick, > First of all, please try out the patch that I am about to upload. It may be > that the problem is that the linker is garbage collecting sections that are > really needed, because the linker script failed to mark those sections as > KEEP. (You may need to check that the linker script you are using is the one > that is fixed by the uploaded patch. Add -Wl,--verbose to the gcc command > line to check this). The only difference I see is that the exception tables are preserved with 2.26 and your patch. I'm attaching the logs of two builds with --verbose and --print-gc-sections, one with ld 2.25.90.20151209 (the version where we saw this starting) and one with ld 2.26 and your patch. > If that does not work then try adding -Wl,--print-gc-sections to the bad DLL > creation command line. See what gets thrown away, see if this matches up with > the undefined symbols, and try to work out why they are being thrown away. There are a lot of sections being thrown away, and they do match the undefined symbols. I haven't figured out why they're being thrown away yet. Regards, Stephen
Created attachment 9110 [details] Build log for libstdc++-v3 with ld 2.25.90.20151209
Created attachment 9111 [details] Build log for libstdc++-v3 with ld 2.26 and Nick's patch
For completeness' sake I tried patch 7 from #19803 too, and I get the same build log.
Hi Stephen, Did you see the patch for PR 19531 go in ? I think that it might be relevant here too.. The only other thing that I can think of is the new, extra, patch that has been uploaded to PR 19803. I think that I am correct in saying that the 32-bit mingw uses an underscore prefix, right ? If so, then this extra patch may be exactly what is needed. Cheers Nick