-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Change name when outputting staticlibs on Windows #29520
Conversation
I'm a little worried about this being a breaking change to existing tooling, for example this will break Cargo and presumably any existing scripts and such used on Windows today, such as some tests we have as well. I sympathize though in that the "best name" here is probably |
I'm not really sure what's a good way to handle the transition. Would Cargo have to first be modified to handle both cases? I could also change this PR so it only affects -msvc and not all of Windows, which wouldn't break all the people using msys and mingw. I'll look into fixing up the tests in the meantime though. |
Ideally on the Cargo side of things it would support both names to run with older and future compilers, but it would unfortunately still break all older Cargo instances working with newer compilers (which currently works today). I never really fully understood these naming conventions for MinGW/MSYS, there certainly seem to be a lot of |
With -msvc, when creating a dylib it'll produce a For -gnu, when creating dylibs, no import library is produced. This means that we have several choices, |
cc @vadimcn, @brson, curious on your thoughts here as well. I'm fine leaving |
My first reaction is that I don't like the direction this takes us in terms of increasing the rift between Would it be feasible to tweak names of the import libraries instead? |
It is possible to tweak the name of the import library that is created. I went with the |
What I don't like about |
Any transformation which applies to all platforms would just cause a significant amount of breakage. I'd prefer if this only affected Windows platforms to minimize that. |
Yeah, I am not really proposing doing that, but hypothetically that would be one way to fix the problem and keep all platforms consistent. Since implibs exist only on Windows, IMO it makes more sense to rename them, not normal libs. We should also consider changing the |
What naming convention do you propose for the import library? |
How about one of these?: |
Of those options, I feel least opposed to |
6d59d98
to
6f28456
Compare
I've updated the PR to now make static libraries |
6f28456
to
bb63b15
Compare
Okay, it seems to be working now. Feel free to bikeshed some more if you think this isn't the way to do it. |
bb63b15
to
3e315d0
Compare
lgtm |
Now to fix all the tests that expect things to have a different name... |
Tagging this with T-tools to ensure this comes up during triage, I fear there are ramifications here that need to be handled beyond "just renaming artifacts" and I'd just want to make sure to get a few extra opinions. |
We talked about this in the tools triage meeting today and the conclusion was to move forward with this. @retep998 feel free to ping when the tests are passing. |
9d55090
to
1188ae0
Compare
I have tests passing for |
libfoo.a -> foo.lib In order to not cause conflicts, changes the DLL import library name foo.lib -> foo.dll.lib Fixes rust-lang#29508 Because this changes output filenames this is a [breaking-change] Signed-off-by: Peter Atashian <retep998@gmail.com>
Signed-off-by: Peter Atashian <retep998@gmail.com>
51f8131
to
1b0064e
Compare
@alexcrichton Tests are passing on both targets locally. I've rebased and squashed the commits nicely. r? |
|
||
fn build_dylib(&mut self, out_filename: &Path) { | ||
self.cmd.arg("/DLL"); | ||
let mut arg: OsString = "/IMPLIB:".into(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a comment here explaining why this flag is passed?
As I mentioned above as well I'm still worried that this patch will break Cargo, and after reviewing some of the related code I can confirm that it will indeed break Cargo on basically any MSVC build with a I think that we'll need to figure out how to mitigate that breakage before we land this patch to the compiler. |
Required for rust-lang/rust#29520 Signed-off-by: Peter Atashian <retep998@gmail.com>
Ok, with rust-lang/cargo#2299 proposed I'll just want to hold off on merging this until after the release, then this should ride the trains normally into the stable release just fine. |
I'm not sure if this was the best way to go about it, but it seems to work. Fixes #29508 r? @alexcrichton
A few small tweaks to tests were necessary to accomodate rust-lang/rust#29520, and a few changes were made to the code to account for that as well.
A few small tweaks to tests were necessary to accomodate rust-lang/rust#29520, and a few changes were made to the code to account for that as well.
I'm not sure if this was the best way to go about it, but it seems to work.
Fixes #29508
r? @alexcrichton