-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build an empty project failed (undefined reference to `__onexitbegin') #49078
Comments
I also have this issue. I'd bet the cause is the same as #48272, the version of crt2.o included with the |
Much simpler to just copy c:\msys64\mingw64\x86_64-w64-mingw32\lib\crt2.0 to c:\Users%USER%.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-gnu\lib\ |
As far as I can tell, this happens because |
@mati865: compatible with what? The -gnu target is supposed to use the bits of mingw bundled with it, not mingw toolchain installed on your machine. Also, consider that x86_64-pc-windows-gnu toolchain works just fine, and the only difference is that it does contain the @alexcrichton: Could |
As I said, I don't deny that it's possible to run into compatibility problems when external C/C++ is involved. However, I think it's still perfectly fair to expect |
It would probably be pretty easy to add dependencies to wire this up but I would be wary to do so. Linking with our MinGW target is extremly fiddly and any change tends to have rippling effects causing regressions. I don't really personally want to lead the charge to do this, and unless we have someone willing to help handle the fallout I would discourage a change to the distribution strategy. |
Right now that target doesn't work at all, how could it get worse? |
At least in my experience it tends to not be that cut and dry, but again I'm not against doing this I just do not personally want to lead the charge to do so. Someone else is always more than welcome to do so. |
I'm having the same (or similar) issue when cross-compiling from Linux to Windows:
I'm on ArchLinux and followed the cross-compilation guide from gtk-rs |
@rustbot modify labels: -O-windows +O-windows-gnu @azymohliad you can use workaround from #47048 but change paths for Linux. |
@mati865 Could you link to the exact comment which has the work around? And what exactly needs to be changed for cross compiling from Linux? I can't seem to figure it out. |
@ChristopherRabotin #47048 (comment) but for me copying the libs is enough ( |
Probably a duplicate of #53454. |
Getting this trying to cross-compile from current Arch packages. Tried I did take a look at the workaround, but I'm not running on Windows. So I don't have a C: apart from wine :). And I won't get to running this until I can build it. |
@spease for this issue the workaround is copying libs like I said 2 comments above. |
These have to be copied from mingw installed on Windows though. |
No, you can use mingw from AUR. See the Arch wiki: https://wiki.archlinux.org/index.php/Rust#Windows |
crt2.o and dllcrt2.o have to be copied over. |
windows-gnu: prefer system crt libraries if they are available This is my proposal (based on `Amanieu`'s idea) on how to fix #47048 and related issues. The origin of the issue is the fact Rust ships mingw-w64 libraries but no headers and prefers own libraries over the system ones. This leads to situation when headers aren't compatible with libraries (mingw-w64 doesn't provide any forward compatibility and AFAIK backwards compatibility is guaranteed only within major release series). It's easier to understand how this PR works when looking at the linker invocation before and with this PR: https://www.diffchecker.com/GEuYFmzo It adds system libraries path before Rust libraries so the linker will prefer them. It has potential issue when system has files with the same names as Rust but that could be avoided by moving Rust shipped mingw-w64 libraries from `lib/rustlib/x86_64-pc-windows-gnu/lib` to say `lib/rustlib/x86_64-pc-windows-gnu/lib/mingw`. Then adding linker paths in this order: Rust libraries, system libraries, Rust shipped mingw-w64 libraries. I don't know if it's worth to cache system libraries path. You can look for `cache: ` string during build Rust: https://pastebin.com/kGEQZGWP I think there are enough calls to justify caching. Fixes #47048 Fixes #49078 Fixes #53454 Fixes #60912
toolchain:
build command:
cargo run --target x86_64-pc-windows-gnu
error message:
possible reason:
rustc bug?
rustlib bug?
msys2 gcc issues?
The text was updated successfully, but these errors were encountered: