Skip to content

make check fails on c-dynamic-dylib on windows #28019

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

Closed
Marwes opened this issue Aug 26, 2015 · 7 comments
Closed

make check fails on c-dynamic-dylib on windows #28019

Marwes opened this issue Aug 26, 2015 · 7 comments
Labels
C-bug Category: This is a bug. O-windows Operating system: Windows T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@Marwes
Copy link
Contributor

Marwes commented Aug 26, 2015

Running make check fails with this error message when run in on windows.

------ stderr ---------------------------------------------
error: linking with `gcc` failed: exit code: 1
note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-static-libgcc" "-m64" "-L" "C:\Users\Markus\rust\x86_64-pc-windows-gnu\stage2\bin\rustlib\x86_64-pc-windows-gnu\lib" "C:/Users/Markus/rust/x86_64-pc-windows-gnu/test/run-make/c-dynamic-dylib\foo.o" "-o" "C:/Users/Markus/rust/x86_64-pc-windows-gnu/test/run-make/c-dynamic-dylib\foo.dll" "C:/Users/Markus/rust/x86_64-pc-windows-gnu/test/run-make/c-dynamic-dylib\foo.metadata.o" "-L" "C:\Users\Markus\rust\x86_64-pc-windows-gnu\stage2\bin\rustlib\x86_64-pc-windows-gnu\lib" "-l" "std-d8ace771" "-L" "C:/Users/Markus/rust/x86_64-pc-windows-gnu/test/run-make/c-dynamic-dylib" "-L" "C:\Users\Markus\rust\x86_64-pc-windows-gnu\stage2\bin\rustlib\x86_64-pc-windows-gnu\lib" "-L" "C:\Users\Markus\rust\src\test\run-make\c-dynamic-dylib\.rust\bin\x86_64-pc-windows-gnu" "-L" "C:\Users\Markus\rust\src\test\run-make\c-dynamic-dylib\bin\x86_64-pc-windows-gnu" "-Wl,-Bstatic" "-Wl,-Bdynamic" "-l" "cfoo" "-l" "ws2_32" "-l" "userenv" "-l" "advapi32" "-shared" "-l" "compiler-rt"
note: C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lcfoo
collect2.exe: error: ld returned 1 exit status

error: aborting due to previous error
make[1]: *** [all] Error 101

------        ---------------------------------------------

/c/Users/Markus/rust/mk/tests.mk:1070: recipe for target 'x86_64-pc-windows-gnu/test/run-make/c-dynamic-dylib-2-T-x86_64-pc-windows-gnu-H-x86_64-pc-windows-gnu.ok' failed
make: *** [x86_64-pc-windows-gnu/test/run-make/c-dynamic-dylib-2-T-x86_64-pc-windows-gnu-H-x86_64-pc-windows-gnu.ok] Error 2

I don't get why gcc is unable to find cfoo as the library file exists in C:/Users/Markus/rust/x86_64-pc-windows-gnu/test/run-make/c-dynamic-dylib and "-L" "C:/Users/Markus/rust/x86_64-pc-windows-gnu/test/run-make/c-dynamic-dylib" is passed to gcc.

Might be related to #18733

@vadimcn
Copy link
Contributor

vadimcn commented Aug 29, 2015

Does set MSYSTEM=MINGW32 help?

@Marwes
Copy link
Contributor Author

Marwes commented Aug 29, 2015

Running MSYSTEM=MINGW32 make check does work.

@steveklabnik steveklabnik added O-windows Operating system: Windows A-build labels Sep 3, 2015
@vadimcn
Copy link
Contributor

vadimcn commented Sep 14, 2015

[Exaplanataion]

  1. Rust's make-test makefile looks for the MINGW substring in uname output to identify Windows and gets very confused when it doesn't find one.
  2. By default MSYS2's uname identifies the host system as MSYS_NT-X.Y, (e.g. MSYS_NT-6.3).
    However, for compatibility with mingw, this prefix may be overridden by setting MSYSTEM environment variable:
C:\>uname
MSYS_NT-6.3
C:\>set MSYSTEM=MINGW32&uname
MINGW32-NT-6.3

@Diggsey
Copy link
Contributor

Diggsey commented Sep 14, 2015

It depends how you start the msys terminal: if you run msys2_shell.bat, then uname returns MSYS_NT-X.Y as you say, but you should be starting it by running mingw32_shell.bat or mingw64_shell.bat in which case uname will give the correct output: MINGW64_NT-X.Y or MINGW32_NT-X.Y. This is needed to make sure that the correct gcc is used as well.

@nodakai
Copy link
Contributor

nodakai commented Apr 4, 2016

Then shouldn't configure abort upon finding uname=MSYS*, perhaps with a message pointing to this ticket?

@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 22, 2017
@steveklabnik
Copy link
Member

Triage: I'm not an mys user, and the build system has been completely re-written since then. Does anyone know of reproduction instructions for this bug today?

@jonas-schievink jonas-schievink added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) and removed A-build labels Apr 21, 2019
@mati865
Copy link
Contributor

mati865 commented Sep 8, 2020

Test no longer use uname to distinguish Windows, I think we can close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. O-windows Operating system: Windows T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

No branches or pull requests

9 participants