MINGW-packages
MINGW-packages copied to clipboard
LD linker fails with GCC+LTO+`-Wa,-mbig-obj`
Hello,
when compiling and linking with the 64-bit gcc with -flto, the linker failes with: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: release/main.o: plugin needed to handle lto object.
The 32-bit version of the compiler in the same msys2 installation works without this issue.
Win 10, actual msys2, starting shells with mingw64.exe resp. mingw32.exe.
Any idea, where to dig in to solve the problem?
Sounds like this problem.
It sounds similar, but unfortunately the proposed solution there does not work.
As this issue seems to be unknown here, there are two options:
a) nobody is using lto with the 64 bit compiler b) my installation has an issue, which is not common
To be sure that b) is the case, can anybody confirm that lto with the 64 bit compiler works?
Oliver
64bit with lto works for me, exactly with this solution.
After doing some more trials it is the combination with -Wa,-mbig-obj, which seems to create the problem. Simple test programs work fine with the standard installation (without the bfd-plugins "fix").
google finds this one here: https://bugs.archlinux.org/task/53859
which is apparently the problem, but unfortunatedly it doesn't really help. At least I don't understand the comment.
Any ideas, where to search for more info?
Oliver
Is there a solution? I need the -Wa,-mbig-obj because of huge header libraries I use (Eigen and ExprTk) and I'm also in need of LTO because linking with MinGW64 (as of 7.1.0 version) is painfully slow for me (5 minutes for a 5MB EXE).
Here is my project in GitHub if it helps: https://github.com/PauloCarvalhoRJ/gammaray . If you try to compile it with MinGW64, you'll see linking takes quite a while for a program that can be considered small by current standards.
@OliverSCE Please consider closing this issue if it is already fixed. If not, Please provide a minimal reproducer to test with.
Still open.
echo "int main(){} >test.cpp gcc -O3 -flto test.cpp -Wa,-mbig-obj
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccRnQMhA.o: plugin needed to handle lto object
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o): in function main': C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18: undefined reference to
WinMain'
collect2.exe: error: ld returned 1 exit status
Oliver
I have asked for minimal reproducer.
What do you mean? Code quoted in previous post is minimal and reproduces the issue.
What do you mean? Code quoted in previous post is minimal and reproduces the issue.
Sorry, haven't notice.
I just noticed that this is my older issue entry regarding this problem.
To be precise in the answer to the question, if this issue is still open: The issue was actually fixed for gcc 8.x.x - 11.1.0 (which came out after my initial post), but is back in more recent versions still today.
Oliver
hi @OliverSCE ,I met same issue which you mentioned! i use mingw64 gcc8.1.0 x64 builds with -wa,-mbig-obj flags, did you has any helpful suggestions to solve this?
At the time of writing, the latest gcc version is 12.2.0. Please update all the packages.
did you has any helpful suggestions to solve this?
No. If you have this issue, the only fix is moving to another MinGW version, until this issue gets addressed and fixed in the msys2 binutils.
At the time of writing, the latest gcc version is 12.2.0. Please update all the packages.
That' s always a good idea, however, it does not help here.
Oliver
If you want to it to be fixed you should report it to Binutils project.
I did a very short check with a debug-build of ld. ld gets a segment with unexpected flags, and throws the error. Its therefor unclear if this a gcc or a binutils (ld) issue.
But the real issue is that this issue exists over several months. Apparently no one is really using this.
Oliver
I'd exert extra care when using the "no one" label. VTK 9 now includes the header-only ExprTK which does not compile without the -Wa,-mbig-obj
flag. Dropping its support means dropping all their users. Just my two cents.
I used msys2 mainly for QT development, which requires the -Wa,-mbig-obj since ever. -Wa,-mbig-obj is not completely unusable, only link time optimization does not work with this flag.
If "no one" is using linkt time optimization for such projects, or "no one" is using msys2 with Qt, or no one is using this at all, I can't say. What I can say that if only someone like me as a pure hobby programmer does complain about such an issue seems to be strange.
Oliver
@OliverSCE: Many years ago I went spelunking around this issue and came to the conclusion that ld was the main problem and not the compiler:
https://sourceforge.net/p/mingw-w64/discussion/723797/thread/c6b70624/
That being said, I don't know what the current situation/resolution wrt this issue would be.
@MehdiChinoune: the project noted in the sourceforge comment, can be used to repro the issue.