Bug: go build . does not function on windows using mingw
Peliex opened this issue · 6 comments
Version
main @da178a5
What happened?
Seems to be an issue with either mingw or go, cannot build the application on Windows as of right now because I cannot figure out how to resolve these linker errors.
The issue actually lies within rust, which doesn't properly link against ntdll.dll on windows when targeting gnu. Unsure how to fix this, not familiar with rust or go.
using https://github.com/niXman/mingw-builds-binaries version 13.1.0 for MinGW
changing CC=g++
causes GTK to not compile because it is a c project.
Reproduction
- Install Rust (latest)
- Install Go (latest)
- Set Go environment vars
go env -w CGO_ENABLED=1
- run
cargo build --release
inthird_party/sdmmparser/src
- run
go build .
in repository root - Observe output linker errors
Relevant log output
# sdmm
C:\Program Files\Go\pkg\tool\windows_amd64\link.exe: running g++ failed: exit status 1
Warning: corrupt .drectve at end of def file
W:/Software/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: W:\\Projects\\StrongDMM\\third_party\\sdmmparser\\src\\target\\release/libsdmmparser.a(sdmmparser-2198e34f47de4299.sdmmparser.92fe8a3acf4477ef-cgu.2.rcgu.o): in function `std::sys::windows::c::NtWriteFile':
/rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library\std\src\sys\windows/c.rs:304: undefined reference to `NtWriteFile'
W:/Software/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: W:\\Projects\\StrongDMM\\third_party\\sdmmparser\\src\\target\\release/libsdmmparser.a(sdmmparser-2198e34f47de4299.sdmmparser.92fe8a3acf4477ef-cgu.2.rcgu.o): in function `std::sys::windows::handle::Handle::synchronous_write':
/rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library\std\src\sys\windows/handle.rs:319: undefined reference to `RtlNtStatusToDosError'
W:/Software/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: W:\\Projects\\StrongDMM\\third_party\\sdmmparser\\src\\target\\release/libsdmmparser.a(sdmmparser-2198e34f47de4299.sdmmparser.92fe8a3acf4477ef-cgu.2.rcgu.o): in function `std::sys::windows::c::NtReadFile':
/rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library\std\src\sys\windows/c.rs:281: undefined reference to `NtReadFile'
W:/Software/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: W:\\Projects\\StrongDMM\\third_party\\sdmmparser\\src\\target\\release/libsdmmparser.a(sdmmparser-2198e34f47de4299.sdmmparser.92fe8a3acf4477ef-cgu.2.rcgu.o): in function `std::sys::windows::handle::Handle::synchronous_read':
/rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library\std\src\sys\windows/handle.rs:273: undefined reference to `RtlNtStatusToDosError'
collect2.exe: error: ld returned 1 exit status```
Did you do that https://github.com/SpaiR/StrongDMM#for-windows?
@Peliex Can you address the comment?
Personally, I do not have problems with configuring build for Windows. Moreover, binaries for Win are built on Windows. (CI job can be checked publically.) So please, tell me if there is something unclear about that.
@Peliex Can you address the comment?
Personally, I do not have problems with configuring build for Windows. Moreover, binaries for Win are built on Windows. (CI job can be checked publically.) So please, tell me if there is something unclear about that.
Using a default configuration of mingw and gcc did not work properly, did you use MSYS2? I can certainly give that a try and see if it resolves the dependency issues
I mean, which rust toolchain do you use? From the log I see there is a problem when it links Go with rust binaries. That is what is described here: https://github.com/SpaiR/StrongDMM#for-windows
Close since no answer
I had this same problem, and I'm sure there are loads of reasons why it might happen, but for anyone in the future that may have the same issue, my rust was defaulted to "stable-x86_64-pc-windows-msvc" (MSVC, which Go does not support)
Once I ran rustup install 1.69-x86_64-pc-windows-gnu
and rustup default 1.69-x86_64-pc-windows-gnu
like in the workflow it worked cleanly.