Skip to content
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

[MSVC] Rustc is producing inappropriate filetypes w/ --crate-type=dylib && --crate-type=staticlib. #28025

Closed
DiamondLovesYou opened this issue Aug 26, 2015 · 4 comments

Comments

@DiamondLovesYou
Copy link
Contributor

For example:

/C/msys64/home/Richard/rust-build/x86_64-pc-windows-msvc/stage2/bin/rustc.exe --out-dir /C/msys64/home/Richard/rust-build/x86_64-pc-windows-msvc/test/run-make/output-type-permutations -L /C/msys64/home/Richard/rust-build/x86_64-pc-windows-msvc/test/run-make/output-type-permutations foo.rs --crate-type=staticlib

produces just libbar.a.

 /C/msys64/home/Richard/rust-build/x86_64-pc-windows-msvc/stage2/bin/rustc.exe --out-dir /C/msys64/home/Richard/rust-build/x86_64-pc-windows-msvc/test/run-make/output-type-permutations -L /C/msys64/home/Richard/rust-build/x86_64-pc-windows-msvc/test/run-make/output-type-permutations foo.rs --crate-type=dylib

produces bar.dll, bar.exp, and bar.lib.

Note rlib output works as expected. See output-type-permutations from run-make.

@nagisa
Copy link
Member

nagisa commented Aug 26, 2015

What’s the issue here? Is the test failing, are the files not accepted by the LINK.EXE or it is simply extensions being not as expected?

.lib may also be an import library without which .dll is pretty much useless. This is probably a reason why dylib emits both .lib and .dll at once. .exp appears to have a similar purpose.

.a should probably be .lib, but then it is ambiguous in case of flag like --crate-type=staticlib,dylib which should produce both and if we try to emit .lib in both cases, we will simply either not emit the static library, or emit an useless dynamic library.

@DiamondLovesYou
Copy link
Contributor Author

What’s the issue here? Is the test failing, are the files not accepted by the LINK.EXE or it is simply extensions being not as expected?

See #27938 (comment). I don't really know the cause, I use Linux or ssh into a Linux box when I'm on my Surface (my only windows machine) and thus aren't familiar with MSVC's conventions. Whatever the real issue, the test is failing, so I just made the test a no-op on MSVC and filed this issue.

@alexcrichton
Copy link
Member

Ok, I've got a branch with this test passing, so I'm going to close this as "working as intended"

@retep998
Copy link
Member

The msvc conventions are:

  • When building a DLL, emit foo.lib and foo.dll. Downstream code will link to foo.lib and acquire a runtime dependency on foo.dll.
  • When building a static library, emit foo.lib. Downstream code will link to foo.lib.
  • foo.exp is used when you create foo.lib and foo.dll as two separate steps. foo.exp will be created alongside foo.lib and foo.exp is then passed to the linker to create foo.dll. Beyond that you don't need the foo.exp file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants