-
Notifications
You must be signed in to change notification settings - Fork 142
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 failure on Windows: #39
Comments
It looks like you're trying to cross-compile 64-bit to 32-bit using MinGW, and MinGW doesn't support that.
|
I'm writing bindings for the R programming language. Our toolchain has both x32 and x64 compilers. How does rust find the proper gcc.exe? Does it just take whatever is first in the path? Can I pass it custom paths to gcc for WIN32 and WIN64 somehow? |
There's *-gnu target that searches for MinGW only, and *-msvc target that looks up Visual Studio installation it the registry. Run: rustup default stable-x86_64-pc-windows-msvc to switch. |
Our entire system is compiled with the mingw-w64 toolchain, so it won't link with msvc. I think I need something like this to point rust to the correct toolchain: rust-lang/cc-rs#82 |
Doesn't |
I added this to my
That seems to have some effect but unfortunately my toochain is static so rust is passing the wrong libs to the linker. |
I'm not sure what you mean by the toolchain being static. |
Our mingw-w64 gcc toolchain is configured as described here. Because it has been configured with Also our toolchain has been compiled with pthreads support. For whatever reason that does not seem to work well with rust: https://ci.appveyor.com/project/jeroen/gifski/build/1.0.23 |
I don't really understand how/where rust is invoking the gcc compiler. It is complaining about missing pthread symbols. Usually when we compile an application that requires pthreads we need to pass |
There are two places where Rust invokes C compiler:
In the first case every dependency is responsible for declaring which libraries are needed by printing linking info in their build scripts. In the second case you shouldn't need to do anything at all if Rust is installed correctly and dependencies aren't buggy. If some buggy dependency failed to declare it needs libpthread, you may work around it by adding |
Thanks for your help! The weird thing is that the line that fails does have
|
Your paths still show mix of "x86_64" and "i686". It's possible that it's not seeing symbols, because it's looking for 32-bit ones in a 64-bit library. You're making it extra hard by doing cross-compilation. Use 32-bit Rust for 32-bit executables. With Rustup it's trivial to switch back and forth, you don't need to reinstall anything. |
OK I found the issue. My mingw-w64 toolchain is OK, however our build does not have Now I need to figure out why rust insists on linking against |
Do you know where the call that links gcc_eh comes in? Is it here? https://github.com/rust-lang/rust/blob/385ef1514c80fb8c0cb061dc69eb1d953a84e2b3/src/libunwind/build.rs#L38 |
libunwind handles libgcc and libgcc_eh are distinct, so I'm surprised the renaming worked :) GCC should always have this library, so if it's not found, it maybe due to missing library search path or mix-up of toolchains. You could try adding to [profile.release]
panic = "abort" which disables panics and theoretically makes the library unnecessary, but I don't know if that will save you from it being linked. |
Right, compiling with The problem is not the path but that our gcc has been configured with --static-gcc so therefore all runtime libs get included with |
The
lodepng
dependency problem is fixed, but now it fails like below. Is this a problem with my gcc?The text was updated successfully, but these errors were encountered: