I don't know if this is a GCC or ld bug, but as the error happens in the link stage, I'm posting it here. To reproduce: class.h ------- class A { public: virtual ~A() {} }; class B : public A { public: ~B() {} }; class.cpp --------- #include "class.h" // just make sure there's more than one object file main.cpp #include "class.h" int main() { B b; return 0; } Compile with "g++ -flto" from the 4.6 branch and link with "g++ -flto" which invokes ld and collect2. Produced errors: release/class.o (symbol from plugin):(.text+0x0): multiple definition of `typeinfo for A' release/main.o (symbol from plugin):(.text+0x0): first defined here release/class.o (symbol from plugin):(.text+0x0): multiple definition of `typeinfo name for A' release/main.o (symbol from plugin):(.text+0x0): first defined here release/class.o (symbol from plugin):(.text+0x0): multiple definition of `typeinfo for B' release/main.o (symbol from plugin):(.text+0x0): first defined here release/class.o (symbol from plugin):(.text+0x0): multiple definition of `typeinfo name for B' release/main.o (symbol from plugin):(.text+0x0): first defined here collect2: ld returned 1 exit status Please note that compiling Qmake (when configuring Qt) or a larger C++ project with -flto produces multiple definitions of stuff like std::allocator operator new and other standard C++ stuff.
I could not reproduce this with current ld. Can you show the output of your "g++ -flto" link with -Wl,-v added to the command line?
Here's all the link commandline and output (taken from a Qt qmake generated makefile): g++ -c -std=c++0x -flto -O2 -frtti -fexceptions -mthreads -Wall -I"..\..\Source\test" -I"." -I"..\Qt\mkspecs\win32-g++" -o release\main.o ..\..\Source\test\main.cpp g++ -c -std=c++0x -flto -O2 -frtti -fexceptions -mthreads -Wall -I"..\..\Source\test" -I"." -I"..\Qt\mkspecs\win32-g++" -o release\class.o ..\..\Source\test\class.cpp M:\Development\x64\test>g++ -flto -Wl,-v -Wl,-s -Wl,-subsystem,console -mthreads -o release\test.exe release/main.o release/class.o collect2 version 4.6.1 20110515 (prerelease)(x86_64 MinGW m:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/bin/ld.exe -plugin m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.1/liblto_plugin-0.dll -plugin-opt=m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.1/lto-wrapper.exe -plugin-opt=-fresolution=C:\Users\Ruben\AppData\Local\Temp\cccAGScb.res -plugin-opt=-pass-through=-lmingwthrd -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingwthrd -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt --sysroot=m:\development\mingw64\bin\../../mingw64 -m i386pep -Bdynamic -o release\test.exe m:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o m:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/lib/../lib/crtbegin.o -Lm:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1 -Lm:/development/mingw64/bin/../lib/gcc -Lm:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/lib/../lib -Lm:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../lib -Lm:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/lib -Lm:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../.. -v -s -subsystem console release/main.o release/class.o -lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt m:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/lib/../lib/crtend.o GNU ld (GNU Binutils) 2.21.51.20110515 release/class.o (symbol from plugin):(.text+0x0): multiple definition of `typeinfo for A' release/main.o (symbol from plugin):(.text+0x0): first defined here release/class.o (symbol from plugin):(.text+0x0): multiple definition of `typeinfo name for A' release/main.o (symbol from plugin):(.text+0x0): first defined here release/class.o (symbol from plugin):(.text+0x0): multiple definition of `typeinfo for B' release/main.o (symbol from plugin):(.text+0x0): first defined here release/class.o (symbol from plugin):(.text+0x0): multiple definition of `typeinfo name for B' release/main.o (symbol from plugin):(.text+0x0): first defined here collect2: ld returned 1 exit status
Created attachment 5723 [details] testcase, exact one that's producing the error Concrete files that produce given error messages
Seems this is PE specific. Testcase passes on powerpc-linux.
Changed the target to all architectures of mingw after further testing. This problem also pops up when building libstdc++ with a GCC cross compiler to x86_64-w64-mingw32 or i686-w64-mingw32 with CFLAGS="-flto" (check libstdc++'s config.log, "make" will fail somewhere else due to a failed configure test).
When compiling libstdc++ with -flto in CFLAGS, libstdc++'s config.log shows a failed test with these errors (along with the previous multiple definition errors): `__multf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of multf3.o (symbol from plugin) `__multf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of multf3.o (symbol from plugin) `__multf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of multf3.o (symbol from plugin) `__multf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of multf3.o (symbol from plugin) `__subtf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of subtf3.o (symbol from plugin) `__addtf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of addtf3.o (symbol from plugin) `__subtf3' referenced in section `.text' of /tmp/ccbxHWuQ.ltrans0.ltrans.o: defined in discarded section `.text' of subtf3.o (symbol from plugin) ... In total it seems ld is reading all symbols multiple times in the same object file, and
I use binutils 2.21.53.20110728 and mingw gcc 4.6.1 on windows, the problem is still not fixed.
Created attachment 5869 [details] Possible patch
Hi, As a workaround have you tried adding -Wl,-allow-multiple-definition to the final gcc command line ? I have uploaded a patch that *might* solve this problem. I do not have the build environment in which to fully test it however, so there may well be problems with it. Please give it a go anyway and let me know what happens. Cheers Nick
(In reply to comment #9) > Hi, > > As a workaround have you tried adding -Wl,-allow-multiple-definition to the > final gcc command line ? > > I have uploaded a patch that *might* solve this problem. I do not have the > build environment in which to fully test it however, so there may well be > problems with it. Please give it a go anyway and let me know what happens. > > Cheers > Nick Yea, these days I use -Wl,-allow-multiple-definition to avoid this problem. I will test the patch sometime. Thanks.
(In reply to comment #8) > Created attachment 5869 [details] > Possible patch I test the patch using ruben's testcase, and it seems to work very well. -------------------------------------------- g++ -flto -c main.cpp g++ -flto -c class.cpp g++ -flto -fuse-linker-plugin main.o class.o -------------------------------------------- No errors and no warnings.
Nick, I reckon your patch is covering a bug elsewhere. Symbols in discarded sections are supposed to be treated as undefined. See cofflink.c:396. section_already_linked is supposed to discard duplicate sections. Apparently it doesn't. Ah ha! I see _bfd_generic_section_already_linked is setting SEC_GROUP for the plugin comdat entry in the already_linked list, and then totally ignores any entry with SEC_GROUP set.
Created attachment 5870 [details] fix the real problem
Hi Alan, > Nick, I reckon your patch is covering a bug elsewhere. Oh, definitely. > Symbols in discarded sections are supposed to be treated as undefined. But these sections are not being discarded. The problem, I think is that gcc's LTO framework is trying to use the comdat feature to handle duplicate symbols, but this is not really supported by COFF based targets. > Ah ha! I see _bfd_generic_section_already_linked is setting > SEC_GROUP for the plugin comdat entry in the already_linked list, and then > totally ignores any entry with SEC_GROUP set. I saw that too, but I could not find a way to make it work. > Created attachment 5870 [details] > fix the real problem Did you try this on the test case in this PR ? I had a go locally and it seems that the problem is still there. :-( Either that or I misapplied your patch. Cheers Nick
I don't have a mingw gcc to compile with, so, no I haven't tried the testcase. I suppose I should build a cross-compiler to properly investigate this PR.
(In reply to comment #15) > I don't have a mingw gcc to compile with, so, no I haven't tried the testcase. > I suppose I should build a cross-compiler to properly investigate this PR. There's nice up to date builds of GCC 4.6 and binutils trunk at http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/ and http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/ You could use these and just rebuild the ld component for testing..
OK, I've had a look at this PR again, comparing output from the mingw compiler versus an ELF one. The ELF gcc plugin has multiple copies of _ZTI1A and similar symbols added via ld/plugin.c:add_symbols. The difference is that the ELF gcc makes them weak. That's the reason why ld does not complain for ELF. So this is probably a mingw gcc bug. However, I now think a patch like the one Nick added here is quite safe. An even better version would be to modify bfd_section_already_linked to return a bool saying whether the entry is already there. That will save a lookup, and allow the ELF/COFF versions to be different if necessary. I'll code up a patch to do that.
CVSROOT: /cvs/src Module name: src Changes by: amodra@sourceware.org 2011-08-05 03:17:12 Modified files: bfd : ChangeLog elflink.c linker.c targets.c elf-bfd.h libbfd-in.h libbfd.h bfd-in2.h ld : ChangeLog plugin.c Log message: PR ld/12762 bfd/ * elflink.c (_bfd_elf_section_already_linked): Return matched status. Remove COFF comdat section handling. * linker.c (_bfd_generic_section_already_linked): Return matched status. Don't set SEC_GROUP in l_flags for plugin entries. (bfd_section_already_linked): Update prototype. * targets.c (_section_already_linked): Likewise. * elf-bfd.h (_bfd_elf_section_already_linked): Likewise. * libbfd-in.h (_bfd_generic_section_already_linked): Likewise. (_bfd_nolink_section_already_linked): Update. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate. ld/ * plugin.c (add_symbols): Exclude comdat_key symbols from symbol table if already seen. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5445&r2=1.5446 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?cvsroot=src&r1=1.416&r2=1.417 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/linker.c.diff?cvsroot=src&r1=1.87&r2=1.88 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/targets.c.diff?cvsroot=src&r1=1.206&r2=1.207 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf-bfd.h.diff?cvsroot=src&r1=1.327&r2=1.328 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/libbfd-in.h.diff?cvsroot=src&r1=1.90&r2=1.91 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/libbfd.h.diff?cvsroot=src&r1=1.257&r2=1.258 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/bfd-in2.h.diff?cvsroot=src&r1=1.545&r2=1.546 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ChangeLog.diff?cvsroot=src&r1=1.2360&r2=1.2361 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/plugin.c.diff?cvsroot=src&r1=1.36&r2=1.37
Fixed.
The fix is incorrect and caused PR 13066.
CVSROOT: /cvs/src Module name: src Changes by: amodra@sourceware.org 2011-08-09 09:27:34 Modified files: ld : ChangeLog plugin.c Log message: PR ld/13066 PR ld/12762 * plugin.c (add_symbols): Revert 2011-08-05. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ChangeLog.diff?cvsroot=src&r1=1.2362&r2=1.2363 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/plugin.c.diff?cvsroot=src&r1=1.37&r2=1.38
CVSROOT: /cvs/src Module name: src Changes by: amodra@sourceware.org 2011-08-17 00:39:41 Modified files: bfd : ChangeLog bfd-in.h coff-alpha.c coff-mips.c coffcode.h cofflink.c elf-bfd.h libbfd-in.h targets.c linker.c elflink.c coffgen.c libcoff-in.h libbfd.h libcoff.h bfd-in2.h ld : ChangeLog ldlang.c plugin.c Log message: PR ld/12762 bfd/ * bfd-in.h (struct bfd_section_already_linked): Forward declare. (_bfd_handle_already_linked): Declare. * coff-alpha.c (_bfd_ecoff_section_already_linked): Define as _bfd_coff_section_already_linked. * coff-mips.c (_bfd_ecoff_section_already_linked): Likewise. * coffcode.h (coff_section_already_linked): Likewise. * cofflink.c (coff_link_add_symbols): Revert 2011-07-09 changes. * elf-bfd.h: Likewise. * libbfd-in.h: Likewise. * targets.c: Likewise. * linker.c (bfd_section_already_linked): Likewise. (bfd_section_already_linked_table_lookup): Likewise. (bfd_section_already_linked_table_insert): Likewise. (_bfd_generic_section_already_linked): Likewise. Call _bfd_handle_already_linked. (_bfd_handle_already_linked): New function, split out from.. * elflink.c (_bfd_elf_section_already_linked): ..here. Revert 2011-07-09 changes. Avoid unnecessary strcmp when matching already_linked_list entries. Match plugin linkonce section. (section_signature): Delete. * coffgen.c (_bfd_coff_section_already_linked): New function. * libcoff-in.h (_bfd_coff_section_already_linked): Declare. * libbfd.h: Regenerate. * libcoff.h: Regenerate. * bfd-in2.h: Regenerate. ld/ * ldlang.c (section_already_linked): Revert 2011-07-09 changes. * plugin.c: Likewise. (asymbol_from_plugin_symbol): Create linkonce section for syms with comdat_key. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5458&r2=1.5459 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/bfd-in.h.diff?cvsroot=src&r1=1.156&r2=1.157 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/coff-alpha.c.diff?cvsroot=src&r1=1.47&r2=1.48 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/coff-mips.c.diff?cvsroot=src&r1=1.40&r2=1.41 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/coffcode.h.diff?cvsroot=src&r1=1.180&r2=1.181 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/cofflink.c.diff?cvsroot=src&r1=1.78&r2=1.79 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf-bfd.h.diff?cvsroot=src&r1=1.328&r2=1.329 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/libbfd-in.h.diff?cvsroot=src&r1=1.91&r2=1.92 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/targets.c.diff?cvsroot=src&r1=1.207&r2=1.208 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/linker.c.diff?cvsroot=src&r1=1.88&r2=1.89 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?cvsroot=src&r1=1.417&r2=1.418 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/coffgen.c.diff?cvsroot=src&r1=1.79&r2=1.80 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/libcoff-in.h.diff?cvsroot=src&r1=1.43&r2=1.44 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/libbfd.h.diff?cvsroot=src&r1=1.258&r2=1.259 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/libcoff.h.diff?cvsroot=src&r1=1.60&r2=1.61 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/bfd-in2.h.diff?cvsroot=src&r1=1.547&r2=1.548 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ChangeLog.diff?cvsroot=src&r1=1.2364&r2=1.2365 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?cvsroot=src&r1=1.375&r2=1.376 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/plugin.c.diff?cvsroot=src&r1=1.38&r2=1.39
Created attachment 5912 [details] Qt uic.exe link failure output Hmm, the test case passes, but LTO still can't link an executable: See log for output. There's still multiple definition errors (the first in output.log) and other errors (the last ones in output.log).
(In reply to comment #23) > Created attachment 5912 [details] > Qt uic.exe link failure output > > Hmm, the test case passes, but LTO still can't link an executable: > > See log for output. There's still multiple definition errors (the first in > output.log) and other errors (the last ones in output.log). If I build mingw64 CRT with "-flto", when I use "-flto -fuse-linker-plugin" to build some scientific program ( using the math function such as sin ), it will result in similar errors.
Created attachment 5936 [details] mingw64-testcase Add mingw64 testcase, the source is from mingw64 CRT source. You can build the source code using mingw64 compiler as follows to reproduce the issue: gcc -flto -DHAVE_CONFIG_H -I. -m32 -I./include -D_CRTBLD -pipe -std=gnu99 -c ./math/sin.c gcc -flto -DHAVE_CONFIG_H -I. -m32 -I./include -D_CRTBLD -pipe -std=gnu99 -c ./math/sinl_internal.S gcc -flto -DHAVE_CONFIG_H -I. -m32 -D_SYSCRT=1 -DCRTDLL=1 -I./include -D_CRTBLD -pipe -std=gnu99 -c ./crt/merr.c ar cru libm1.a sin.o sinl_internal.o gcc -flto -fuse-linker-plugin main.c libm1.a merr.o In the end, it will show like this: `___mingw_raise_matherr' referenced in section `.text' of e:/mypack/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/lib/../lib/libmingwex.a(lib32_libmingwex_a-sin.o): defined in discarded section `.text' of merr.o (symbol from plugin) `___mingw_raise_matherr' referenced in section `.text' of e:/mypack/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/lib/../lib/libmingwex.a(lib32_libmingwex_a-sin.o): defined in discarded section `.text' of merr.o (symbol from plugin) collect2: ld returned 1 exit status
(In reply to comment #25) > Created attachment 5936 [details] > mingw64-testcase > > ar cru libm1.a sin.o sinl_internal.o > It's very strange that if I don't use libm1.a, and use the obj directly, it works well. As is: gcc -flto -fuse-linker-plugin main.c sin.o sinl_internal.o merr.o That results in no errors.
I use gcc -flto -fuse-linker-plugin main.c libm1.a merr.o -save-temps to save some intermediate files, and this can generate a .s called ccJ5043j.ltrans0.s. I use the command: gcc -flto -fuse-linker-plugin ccJ5043j.ltrans0.s it shows: e:/mypack/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-merr.o):merr.c:(.text+0x50): multiple definition of `__mingw_setusermatherr' R:\Temp\cchQZ96c.o:ccJ5043j.ltrans0.o:(.text+0xa8): first defined here e:/mypack/mingw/bin/../lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-merr.o):merr.c:(.text+0x60): multiple definition of `_matherr' R:\Temp\cchQZ96c.o:ccJ5043j.ltrans0.o:(.text+0x0): first defined here collect2: ld returned 1 exit status This is different from Comment 25 I can use gcc -flto -fuse-linker-plugin ccJ5043j.ltrans0.s -Wl,--allow-multiple-definition to build successfully. So I think some multiple defined determination in cofflink.c is wrong, which may be identified with discarded section. Any ideas?
Can confirm this for Qt applications with MinGW suite (g++ 4.7.0, ld 2.22).
The ori
The original problem has shifted somewhat. Using GCC 4.7.2 and ld 2.23.51.20120920, the first link error I get now when compiling Qt (where I originally met the issue) with -flto (and of course linking with the same option) is the following: g++ -Wl,-s -mthreads -flto -shared -Wl,--out-implib,d:\Development\x64\Qt\lib\libQtXml4.a -o ..\..\lib\QtXml4.dll tmp/obj/release_shared/qdom.o tmp/obj/release_shared/qxml.o tmp/obj/release_shared/qxmlstream.o -L"d:\Development\x64\Qt\lib" -L"d:\Development\x64\Qt\lib" tmp\obj\release_shared\QtXml_resource_res.o -lQtCore4 R:\ccPQQQpC.ltrans23.ltrans.o:ccPQQQpC.ltrans23.o:(.text+0x1d05): undefined reference to `__imp__ZTV12QTextOStream.local.415.4022' R:\ccPQQQpC.ltrans23.ltrans.o:ccPQQQpC.ltrans23.o:(.text+0x1d43): undefined reference to `__imp__ZTV12QTextOStream.local.415.4022' R:\ccPQQQpC.ltrans23.ltrans.o:ccPQQQpC.ltrans23.o:(.text+0x1d81): undefined reference to `__imp__ZTV12QTextIStream.local.414.4003' R:\ccPQQQpC.ltrans23.ltrans.o:ccPQQQpC.ltrans23.o:(.text+0x1dbf): undefined reference to `__imp__ZTV12QTextIStream.local.414.4003' d:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/bin/ld.exe: R:\ccPQQQpC.ltrans23.ltrans.o: bad reloc address 0x8 in section `.data' collect2.exe: error: ld returned 1 exit status mingw32-make[2]: *** [..\..\lib\QtXml4.dll] Error 1 mingw32-make[2]: Leaving directory `D:/Development/x64/Qt/src/xml' Which means that a bunch of libraries now build, and the Qt build utilities that I believe could not be built are now built fine. The above symbol(s) ran through C++filt say: "vtable for QTextOStream". Another small C++ project consisting of a static library and an app compiles without a hitch with -flto (and it works fine too)
(In reply to comment #30) > The original problem has shifted somewhat. Using GCC 4.7.2 and ld > 2.23.51.20120920, the first link error I get now when compiling Qt (where I > originally met the issue) with -flto (and of course linking with the same > option) is the following: > > > g++ -Wl,-s -mthreads -flto -shared > -Wl,--out-implib,d:\Development\x64\Qt\lib\libQtXml4.a -o ..\..\lib\QtXml4.dll > tmp/obj/release_shared/qdom.o tmp/obj/release_shared/qxml.o > tmp/obj/release_shared/qxmlstream.o -L"d:\Development\x64\Qt\lib" > -L"d:\Development\x64\Qt\lib" tmp\obj\release_shared\QtXml_resource_res.o > -lQtCore4 > R:\ccPQQQpC.ltrans23.ltrans.o:ccPQQQpC.ltrans23.o:(.text+0x1d05): undefined > reference to `__imp__ZTV12QTextOStream.local.415.4022' > R:\ccPQQQpC.ltrans23.ltrans.o:ccPQQQpC.ltrans23.o:(.text+0x1d43): undefined > reference to `__imp__ZTV12QTextOStream.local.415.4022' > R:\ccPQQQpC.ltrans23.ltrans.o:ccPQQQpC.ltrans23.o:(.text+0x1d81): undefined > reference to `__imp__ZTV12QTextIStream.local.414.4003' > R:\ccPQQQpC.ltrans23.ltrans.o:ccPQQQpC.ltrans23.o:(.text+0x1dbf): undefined > reference to `__imp__ZTV12QTextIStream.local.414.4003' > d:/development/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/bin/ld.exe: > R:\ccPQQQpC.ltrans23.ltrans.o: bad reloc address 0x8 in section `.data' > collect2.exe: error: ld returned 1 exit status > mingw32-make[2]: *** [..\..\lib\QtXml4.dll] Error 1 > mingw32-make[2]: Leaving directory `D:/Development/x64/Qt/src/xml' > > Which means that a bunch of libraries now build, and the Qt build utilities > that I believe could not be built are now built fine. > The above symbol(s) ran through C++filt say: "vtable for QTextOStream". > > Another small C++ project consisting of a static library and an app compiles > without a hitch with -flto (and it works fine too) It's very same with http://sourceware.org/bugzilla/show_bug.cgi?id=13031 I use -flto-partition=none to workaround it.
I am seeing this issue while cross-compiling Qt 5.9.0 on Arch Linux via x86_64-w64-mingw32-g++ 7.1.1 with (slim) LTO enabled (the error is reported when linking Qt5Gui.dll): $ x86_64-w64-mingw32-g++ -flto-partition=none -Wl,-s -shared -fno-keep-inline-dllexport -pipe -O3 -std=c++1z -flto=4 -fno-fat-lto-objects -fuse-linker-plugin -Wl,-subsystem,windows -Wl,--out-implib,<left out for brevity>/libQt5Gui.a -o ../../lib/Qt5Gui.dll <list of .o/.a files and -L/-l left out for brevity> .obj/release/qimage_compat.o (symbol from plugin):(.gnu.linkonce.t._ZTS12QPaintDevice+0x0): multiple definition of `typeinfo name for QPaintDevice' .obj/release/qimage_ssse3.o:qimage_ssse3.cpp:(.rdata$_ZTS12QPaintDevice[_ZTS12QPaintDevice]+0x0): first defined here .obj/release/qimage_compat.o (symbol from plugin):(.gnu.linkonce.t._ZTI12QPaintDevice+0x0): multiple definition of `typeinfo for QPaintDevice' .obj/release/qimage_ssse3.o:qimage_ssse3.cpp:(.rdata$_ZTI12QPaintDevice[_ZTI12QPaintDevice]+0x0): first defined here .obj/release/qimage_compat.o (symbol from plugin):(.gnu.linkonce.t._ZTS6QImage+0x0): multiple definition of `typeinfo name for QImage' .obj/release/qimage_ssse3.o:qimage_ssse3.cpp:(.rdata$_ZTS6QImage[_ZTS6QImage]+0x0): first defined here .obj/release/qimage_compat.o (symbol from plugin):(.gnu.linkonce.t._ZTI6QImage+0x0): multiple definition of `typeinfo for QImage' .obj/release/qimage_ssse3.o:qimage_ssse3.cpp:(.rdata$_ZTI6QImage[_ZTI6QImage]+0x0): first defined here .obj/release/qaccessible.o (symbol from plugin):(.gnu.linkonce.t._ZTS7QPixmap+0x0): multiple definition of `typeinfo name for QPixmap' .obj/release/qdrawhelper_ssse3.o:qdrawhelper_ssse3.cpp:(.rdata$_ZTS7QPixmap[_ZTS7QPixmap]+0x0): first defined here .obj/release/qaccessible.o (symbol from plugin):(.gnu.linkonce.t._ZTI7QPixmap+0x0): multiple definition of `typeinfo for QPixmap' .obj/release/qdrawhelper_ssse3.o:qdrawhelper_ssse3.cpp:(.rdata$_ZTI7QPixmap[_ZTI7QPixmap]+0x0): first defined here I tried -flto-partition=none without success while -Wl,-allow-multiple-definition seems to have worked.
I have stumbled upon this bug when cross compiling from Linux to Windows, using GNU ld (GNU Binutils) 2.34 from Ubuntu 20.04 package "binutils-mingw-w64-x86-64". When building a private project with -ltto, I get multiple instances of symbol redefinition error. I also managed to workaround the problem by using -Wl,-allow-multiple-definition.