Skip to content

cargo for x86_64-pc-windows-gnu is broken #3384

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.

Sign up for GitHub

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

Jump to bottom
Closed
retep998 opened this issue Dec 11, 2016 · 8 comments · Fixed by #3393
Closed

cargo for x86_64-pc-windows-gnu is broken #3384

retep998 opened this issue Dec 11, 2016 · 8 comments · Fixed by #3393

Comments

@retep998
Copy link
Member

Specifically x86_64-pc-windows-gnu. No other target is known to be affected.

https://ci.appveyor.com/project/retep998/winapi-rs/build/1.0.1027/job/s9rb4k8hlukyrf87

cargo -vV
Command exited with code -1073741701

That exit code is 0xC000007B STATUS_INVALID_IMAGE_FORMAT.

cc @alexcrichton
@alexcrichton
Copy link
Member

Hm I have yet to see the reproduce elsewhere, and can't reproduce it locally unfortunately. Does this happen deterministically for you? Would it be possible to test this out via AppVeyor's RDP feature to poke around and see what the invalid image is?

@retep998
Copy link
Member Author

retep998 commented Dec 13, 2016 •
edited
Loading

It is deterministic, and I figured out what the issue is. cargo.exe gained a dependency on zlib1.dll which would break cargo for anyone who doesn't happen to have zlib1.dll just laying around.

@alexcrichton
Copy link
Member

That'd do it! I'll look into fixing that.

@alexcrichton alexcrichton mentioned this issue Dec 13, 2016
Merged
alexcrichton added a commit to alexcrichton/cargo that referenced this issue Dec 15, 2016
@alexcrichton
Bump libz-sys to 1.0.9
34b44ce 
This just switches libz to always link statically instead of relying on the
system zlib. For MinGW it seems that linkage may default pull in a DLL, which is
almost never what we want.

Also update curl-sys to fix a build issue on MinGW.

Closes rust-lang#3384
bors added a commit that referenced this issue Dec 15, 2016
@bors
Auto merge of #3393 - alexcrichton:fix-libz-linkage, r=brson
d902f59 
Bump libz-sys to 1.0.9

This just switches libz to always link statically instead of relying on the
system zlib. For MinGW it seems that linkage may default pull in a DLL, which is
almost never what we want.

Closes #3384
brson pushed a commit to brson/cargo that referenced this issue Dec 15, 2016
@alexcrichton @brson
Bump libz-sys to 1.0.9
7057d6a 
This just switches libz to always link statically instead of relying on the
system zlib. For MinGW it seems that linkage may default pull in a DLL, which is
almost never what we want.

Also update curl-sys to fix a build issue on MinGW.

Closes rust-lang#3384
@snuk182 snuk182 mentioned this issue Dec 15, 2016
Closed
alexcrichton added a commit to brson/cargo that referenced this issue Dec 15, 2016
@alexcrichton
Bump libz-sys to 1.0.9
3aff2ad 
This just switches libz to always link statically instead of relying on the
system zlib. For MinGW it seems that linkage may default pull in a DLL, which is
almost never what we want.

Also update curl-sys to fix a build issue on MinGW.

Closes rust-lang#3384
@eminence
Copy link
Contributor

Since I can't run cargo --version, what's the best way to track this fix (and to see when it'll be available via a rustup update)?

@retep998
Copy link
Member Author

@eminence You can follow http://rusty-dash.com/nightlies to see when the next Rust nightly comes out.

@retep998 retep998 mentioned this issue Dec 16, 2016
Merged
@eminence
Copy link
Contributor

Thanks! Looks like there was a new nightly release today, and running cargo --verbose works again. Yes there is another crash later on. Do we think this is related to this issue, or is something different?

@alexcrichton
Copy link
Member

@eminence it may be unrelated, but what are the crashes that you're seeing?

@alexcrichton alexcrichton mentioned this issue Dec 16, 2016
Closed
@eminence
Copy link
Contributor

During a cargo build, there was a crash that resulted in a very generic "cargo.exe has crashed" popup. However I can no longer reproduce the issue. i'll continue trying to reproduce and will open a new issue if i figure it out. thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Bump libz-sys to 1.0.9 alexcrichton/cargo
3 participants
@alexcrichton @eminence @retep998