Bug 12762 - LTO on Windows is broken (C++)
Summary: LTO on Windows is broken (C++)
Status: REOPENED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.22
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks: 13066
  Show dependency treegraph
 
Reported: 2011-05-15 15:24 UTC by vanboxem.ruben
Modified: 2017-07-11 12:53 UTC (History)
8 users (show)

See Also:
Host:
Target: *-*-mingw*
Build:
Last reconfirmed:


Attachments
testcase, exact one that's producing the error (352 bytes, application/zip)
2011-05-15 16:02 UTC, vanboxem.ruben
Details
Possible patch (969 bytes, patch)
2011-08-01 14:50 UTC, Nick Clifton
Details | Diff
fix the real problem (414 bytes, patch)
2011-08-02 02:04 UTC, Alan Modra
Details | Diff
Qt uic.exe link failure output (23.35 KB, text/plain)
2011-08-25 14:28 UTC, vanboxem.ruben
Details
mingw64-testcase (5.08 KB, application/octet-stream)
2011-09-18 22:26 UTC, xunxun
Details

Note You need to log in before you can comment on or make changes to this bug.
Description vanboxem.ruben 2011-05-15 15:24:16 UTC
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.
Comment 1 Alan Modra 2011-05-15 15:56:29 UTC
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?
Comment 2 vanboxem.ruben 2011-05-15 16:01:04 UTC
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
Comment 3 vanboxem.ruben 2011-05-15 16:02:31 UTC
Created attachment 5723 [details]
testcase, exact one that's producing the error

Concrete files that produce given error messages
Comment 4 Alan Modra 2011-05-15 23:06:30 UTC
Seems this is PE specific.  Testcase passes on powerpc-linux.
Comment 5 vanboxem.ruben 2011-05-16 20:52:16 UTC
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).
Comment 6 vanboxem.ruben 2011-05-17 13:27:46 UTC
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
Comment 7 xunxun 2011-07-28 13:49:21 UTC
I use binutils 2.21.53.20110728 and mingw gcc 4.6.1 on windows, the problem is still not fixed.
Comment 8 Nick Clifton 2011-08-01 14:50:23 UTC
Created attachment 5869 [details]
Possible patch
Comment 9 Nick Clifton 2011-08-01 14:53:40 UTC
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
Comment 10 xunxun 2011-08-01 14:57:09 UTC
(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.
Comment 11 xunxun 2011-08-01 20:58:52 UTC
(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.
Comment 12 Alan Modra 2011-08-02 02:02:12 UTC
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.
Comment 13 Alan Modra 2011-08-02 02:04:00 UTC
Created attachment 5870 [details]
fix the real problem
Comment 14 Nick Clifton 2011-08-02 10:56:35 UTC
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
Comment 15 Alan Modra 2011-08-02 12:10:18 UTC
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.
Comment 16 vanboxem.ruben 2011-08-03 18:04:23 UTC
(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..
Comment 17 Alan Modra 2011-08-04 23:27:13 UTC
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.
Comment 18 cvs-commit@gcc.gnu.org 2011-08-05 03:17:15 UTC
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
Comment 19 Alan Modra 2011-08-05 03:19:20 UTC
Fixed.
Comment 20 H.J. Lu 2011-08-08 19:23:00 UTC
The fix is incorrect and caused PR 13066.
Comment 21 cvs-commit@gcc.gnu.org 2011-08-09 09:27:38 UTC
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
Comment 22 cvs-commit@gcc.gnu.org 2011-08-17 00:39:45 UTC
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
Comment 23 vanboxem.ruben 2011-08-25 14:28:01 UTC
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).
Comment 24 xunxun 2011-09-17 17:32:33 UTC
(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.
Comment 25 xunxun 2011-09-18 22:26:00 UTC
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
Comment 26 xunxun 2011-09-18 22:30:42 UTC
(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.
Comment 27 xunxun 2011-09-20 23:09:04 UTC
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?
Comment 28 Dmitry 2012-09-06 23:37:44 UTC
Can confirm this for Qt applications with MinGW suite (g++ 4.7.0, ld 2.22).
Comment 29 vanboxem.ruben 2012-09-23 20:22:44 UTC
The ori
Comment 30 vanboxem.ruben 2012-09-23 20:33:53 UTC
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)
Comment 31 xunxun 2013-04-30 09:37:49 UTC
(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.
Comment 32 Martin Schulze 2017-07-11 12:53:57 UTC
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.