msys2 / MINGW-packages

Package scripts for MinGW-w64 targets to build under MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
2.24k stars 1.21k forks source link

latest mingw-w64-binutils has a corrupted "ld" #2186

Closed emmenlau closed 7 years ago

emmenlau commented 7 years ago

When I update mingw-w64-binutils to latest from git, then afterwards I can not build mingw-w64-gcc. gcc will fail already in configure, with error:

configure: error: C compiler cannot create executables
See `config.log' for more details.

From the config.log it seems that all the runtime libraries like msvcrt are suddenly rejected and it can not find valid candidates for them any more.

mati865 commented 7 years ago

I assume you mean mingw-w64-binutils-git. It wasn't updated for one year so most likely patches have to be ported from mingw-w64-binutils.

emmenlau commented 7 years ago

No, actually the problem is really with mingw-w64-binutils, or so I think. Here is what I did:

When I perform the same procedure without the first step (avoid to build and install mingw-w64-binutils) then I do not get this error in mingw-w64-gcc. So I think its mingw-w64-binutils which breaks mingw-w64-gcc, possibly in combination with mingw-w64-crt-git.

Can I try something to debug this issue?

mati865 commented 7 years ago

You have to build mingw-w64-headers-git before mingw-w64-crt-git.

emmenlau commented 7 years ago

Closing as not helpful anymore. Will reopen if issue arises again.

emmenlau commented 7 years ago

I'm a bit at the end of my wit with this issue. I made ~60 compiles of the toolchain on two different computers in the last 2 weeks. In almost all cases, after I build mingw-w64-binutils, I can not compile anymore because ld rejects all standard libraries. This happens practically always, no matter if I build first mingw-w64-binutils or first mingw-w64-gcc or the crt and headers. I tried many combinations, but always get the same problem. I always start from a fresh install of latest toolchain and base-devel, so I am pretty sure the issue can not be corrupted packages.

There have been only two cases where I was successful with building mingw-w64-binutils, but this was after many hours of manual tests, and I can never reproduce this solution later. Its possible that this was after installing random other packages, or some other combinations of things. Maybe there is another package that I am missing outside of toolchain and base-devel? Could you try to reproduce my issue from a fresh install of only toolchain and base-devel, and send me your build log of mingw-w64-binutils?

Please note: mingw-w64-binutils compiles and installs for me, and it brings an ld that matches 100% in size to the official ld from your repository. But the newly compiled ld does not work for further compiles. It rejects all libraries.

mati865 commented 7 years ago

Maybe lib from some msys2 package got pulled because mingw version was unavailable. Packages in binary repo are build with almost everything installed.

mingwandroid commented 7 years ago

I think it'd be good to bring this issue or into the light.

In general, most packages can be built with debugging information by changing the options array. Adding '!strip' 'debug' should allow you to run it through gdb (I then use qt creator to debug it in a user friendly IDE).

You said it:

rejects all standard libraries

.. can you be specific about this? A small self contained program this exhibits this would be good. Adding -v to the compiler command line would show the invocation of ld, and that can then be passed to gdb or qt creator (start and debug external program).

emmenlau commented 7 years ago

@mati865 ok I will try to install a larger set of libraries and see if it changes something. @mingwandroid the binutils I compiled myself fail in building any other package. After I install my self-built binutils, any other package that uses shared libraries will fail already in configure with an error C compiler cannot create executables. In the config log, there is a large number of errors from ld that say something like ignoring incompatible ...path...to...msvcrt and then finally failed to detect a matching msvcrt, for many (all) standard libraries. It rejects the x86_64 libraries in their correct paths (I checked and they exist, and nm correctly reports symbols, so the libs are ok. I will post a config.log soon.

Ede123 commented 7 years ago

ignoring incompatible ...path...to...msvcrt

I recently saw this error when doing personal Inkscape builds (i.e. not related to the mingw64-inkscape). It was caused by an improper CMake configuration. I don't know what specific part caused the issue, but it could hint towards path issues or missing linker flags...

emmenlau commented 7 years ago

After I just closed some possibly unrelated issues, I wanted to confirm that this binutils problem is still valid for me. I could not get around it yet, and it happens from a GUI build as well as from a CI build.

mati865 commented 7 years ago

I'm testing binutils 2.28 and GCC made it to 2nd 3rd stage without errors already. In the past I had rebuild toolchain many times and never got error like yours.

If you get it with fresh MSYS2 it may be caused by OS or hardware damage.

EDIT: Stage 3 now.

emmenlau commented 7 years ago

But @mati865 , did you uninstall all mingw-w64 packages before and only install base-devel and toolchain? Or if not, can you send me a dump of all your installed packages?

mati865 commented 7 years ago

It was done with my main MSYS2 install but I'll try to reproduce it with clean env when I get some time.

emmenlau commented 7 years ago

Or can you send me your package list? Maybe its really an unnamed dependency...

mati865 commented 7 years ago

List is pretty long so posting it here and in attachment.

emmenlau commented 7 years ago

Thanks @mati865 , I'm fetching the packages now, lets see if it helps. Fingers crossed!

mati865 commented 7 years ago

Save info which packages were not installed.

mati865 commented 7 years ago

Fresh MSYS2 updated with 2x pacman -Syu, pacman -S base-devel mingw-w64-x86_64-toolchain --needed. Built binutils 2.28 (commited yesterday lately), installed and now compiling GCC. Configure worked as expected and I'll let it go for 2 stages:

==> Starting build()...
configure: loading site script /etc/config.site
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
checking target system type... x86_64-w64-mingw32
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... no, using cp -p
checking for a sed that does not truncate output... /usr/bin/sed
checking for gawk... gawk
checking for libcilkrts support... no
checking for libitm support... no
checking for libsanitizer support... no
checking for libvtv support... yes
checking for libmpx support... no
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
...
emmenlau commented 7 years ago

Dear @mati865 thanks for all the help! It still fails for me, whereas all other packages I tried work now. I have no idea what I'm doing wrong. Update of mingw-w64-binutils to 2.28 did not help. Install of all your packages did not help. Could you possibly send me your config.log and maybe also a dump of the stdout from building mingw-w64-binutils, so I can see if there are any differences? I am also right now installing a new Windows 7 desktop computer from scratch to see if that helps.

mati865 commented 7 years ago

logs.zip from binutils 2.28 build with my main MSYS2.

EDIT: Correction, mingw*.log were created with main MSYS2 and config.log with fresh.

emmenlau commented 7 years ago

This might be helpful, I will be back with more tests in 30 min...

emmenlau commented 7 years ago

Its not easy to compare. First in config.log there was a minor difference, I had dejagnu installed now and you did not. But removing it did not help. Then I looked through the build stdout, but its very hard to compare, because configure seems to execute multi-threaded and prints multiple messages into the same line. I sort the files to make comparison easier, but its still hard. But from careful comparison there is nothing that jumps to the eye. I'm really at the end of my wit here. I will now test the new machine, hopefully something is different there.

emmenlau commented 7 years ago

Thanks a lot @mati865 , after two weeks of debugging on two Windows computers, finally the third Windows machine behaves differently. I will investigate the difference. I think it might be a permission issue (again), because the other two machines print sometimes pacman warnings that the directory permissions are different between package 755 and file system 750. I will close this issue, but when I find the cause I will report it here for others.

mati865 commented 7 years ago

dejagnu and bc are used for make check and I have them in main MSYS2. They aren't aren't reason.

Permission 750 can be issue indeed but it may get created by buggy installers of some packages.

emmenlau commented 7 years ago

And finally I found the problem, sorry it was on my side. I use the variable MACHINE=$(uname -m) to set a machine-specific target directory in .bashrc. When MACHINE is set to x86_64, it breaks mingw-w64-binutils build. I would have never guessed this as the cause :-( Thanks for all the help!