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

cargo package fails when binary crate depends on library crate #1404

Closed
dwrensha opened this issue Mar 11, 2015 · 2 comments · Fixed by #1406
Closed

cargo package fails when binary crate depends on library crate #1404

dwrensha opened this issue Mar 11, 2015 · 2 comments · Fixed by #1406

Comments

@dwrensha
Copy link

I have a simple project with a library crate and an executable crate that depends on the library crate:

#Cargo.toml

[package]

name = "borked"
version = "0.0.1"

[lib]

name = "borked"
path = "lib.rs"

[[bin]]

name = "borked-exe"
path = "main.rs"
// lib.rs

#![crate_name="borked"]
#![crate_type = "lib"]

pub const X : u32 = 42;
// main.rs

#![crate_name="borked-exe"]
#![crate_type = "bin"]

extern crate borked;

pub fn main() {
    println!("{}", borked::X);
}

I expect to be able to call cargo package successfully on this project, but instead I get an error:

$ cargo --version
cargo 0.0.1-pre-nightly (e4f0662 2015-03-09) (built 2015-03-09)
$ rustc --version
rustc 1.0.0-nightly (12b846ab8 2015-03-09) (built 2015-03-09)
$ cargo package --verbose
warning: manifest has no documentation, homepage or repository. See http://doc.crates.io/manifest.html#package-metadata for more info.
   Packaging borked v0.0.1 (file:///Users/dwrensha/Desktop/test-cargo)
   Archiving Cargo.toml
   Archiving lib.rs
   Archiving main.rs
   Verifying borked v0.0.1 (file:///Users/dwrensha/Desktop/test-cargo)
   Compiling borked v0.0.1 (file:///Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1)
     Running `rustc target/package/borked-0.0.1/lib.rs --crate-name borked --crate-type lib -g -C metadata=dd0cc381a16f4c06 -C extra-filename=-dd0cc381a16f4c06 --out-dir /Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug --emit=dep-info,link -L dependency=/Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug -L dependency=/Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug/deps`
     Running `rustc target/package/borked-0.0.1/main.rs --crate-name borked-exe --crate-type bin -g --out-dir /Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug --emit=dep-info,link -L dependency=/Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug -L dependency=/Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug/deps --extern borked=/Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug/libborked-10dfc3af5b511e89.rlib`
error: extern location for borked does not exist: /Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug/libborked-10dfc3af5b511e89.rlib
target/package/borked-0.0.1/main.rs:6:1: 6:21 error: can't find crate for `borked`
target/package/borked-0.0.1/main.rs:6 extern crate borked;
                                      ^~~~~~~~~~~~~~~~~~~~
error: aborting due to 2 previous errors
failed to verify package tarball

Caused by:
  Could not compile `borked`.

Caused by:
  Process didn't exit successfully: `rustc target/package/borked-0.0.1/main.rs --crate-name borked-exe --crate-type bin -g --out-dir /Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug --emit=dep-info,link -L dependency=/Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug -L dependency=/Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug/deps --extern borked=/Users/dwrensha/Desktop/test-cargo/target/package/borked-0.0.1/target/debug/libborked-10dfc3af5b511e89.rlib` (exit code: 101)
@tupshin
Copy link

tupshin commented Mar 11, 2015

Same. This is blocking me from publishing new versions of my crates.

tupshin added a commit to tupshin/cassandra-sys-rs that referenced this issue Mar 11, 2015
@alexcrichton
Copy link
Member

For now you can work around this by passing --no-verify, I'm working on a fix though.

alexcrichton added a commit to alexcrichton/cargo that referenced this issue Mar 11, 2015
When loading targets to compile, be sure to use the targets from the package
that's being passed down to the compilation step, not the one that was passed in
which is overridden.

Closes rust-lang#1404
bors added a commit that referenced this issue Mar 12, 2015
When loading targets to compile, be sure to use the targets from the package
that's being passed down to the compilation step, not the one that was passed in
which is overridden.

Closes #1404
github-merge-queue bot pushed a commit that referenced this issue Feb 28, 2025
…15245)

### What does this PR try to resolve?

GitHub Runner Images 20250224.5.0+ ship Windows 11 SDK 10.0.26100+
compared to the previous Windows 11 SDK 10.0.22621, which bumped the
UCRT headers. The new UCRT headers use SSE2 types. However, `cc`
versions <= 1.2.15 emit `/arch:IA32` for `x86` Windows targets for
`clang-cl`, which causes compilation errors since `clang-cl` can't find
SSE2 types without `/arch:SSE2` specified (or defaulted). (Note that
MSVC at the time of writing silently accepts and emits instruments for
code using SSE2 types, as opposed to `clang-cl` hard error-ing).

`cc` 1.2.16 contains a fix for this problem,
rust-lang/cc-rs#1425, to correctly emit
`/arch:SSE2` instead of `/arch:IA32` to enable `clang-cl` to find the
SSE2 types. However, cargo's `cc` currently is still on 1.2.13.

To fix this for rust-lang/rust CI, we need to bump anything that
transitively relies on `cc` and tries to use `clang-cl` on `x86` Windows
targets to compile any C/C++ code that transitively use functions or
types that require SSE2 types, such as `<wchar.h>`.

### How should we test and review this PR?

The fix was initially intended for `rustc_{codegen_ssa,llvm}` `cc`, and
based on testing in rust-lang/rust#137724, I was
able to successfully build `rustc_{codegen_ssa,llvm}` with a forked `cc`
based on 1.2.15 which contains the fix from
rust-lang/cc-rs#1425. Note that in the same PR,
while the compiler build succeeded, the build of cargo itself failed
since it transitively used a `cc` *without* the fix to build
`curl-sys`[^dep-chain], which failed as one might expect (`curl-sys`
tries to build C code that uses `<wchar.h>` which runs into the same
problem). Hence, this PR is opened to bump cargo's `cc` to a `cc`
version containing the fix.

### Additional information

This `x86` Windows CI problem is:

- Discussed in
https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/spurious.20.28.3F.29.20i686.20msvc.20errors.
- Tracked by rust-lang/rust#137733.

#### `cc` changelog between 1.2.13 and 1.2.16

<details>
<summary>`cc` changes since 1.2.13 up to and including 1.2.16</summary>

#####
[1.2.16](rust-lang/cc-rs@cc-v1.2.15...cc-v1.2.16)
- 2025-02-28

###### Fixed

- force windows compiler to run in `out_dir` to prevent artifacts in cwd
(#1415)

###### Other

- use `/arch:SSE2` for `x86` target arch (#1425)
- Regenerate windows-sys binding
([#1422](rust-lang/cc-rs#1422))
- Regenerate target info
([#1418](rust-lang/cc-rs#1418))
- Add LIB var when compiling flag_check (#1417)
- Change flag ordering
([#1403](rust-lang/cc-rs#1403))
- Fix archiver detection for musl cross compilation
([#1404](rust-lang/cc-rs#1404))

#####
[1.2.15](rust-lang/cc-rs@cc-v1.2.14...cc-v1.2.15)
- 2025-02-21

###### Other

- Regenerate target info
([#1406](rust-lang/cc-rs#1406))
- Always read from all `CFLAGS`-style flags
([#1401](rust-lang/cc-rs#1401))
- Simplify the error output on failed `Command` invocation
([#1397](rust-lang/cc-rs#1397))

#####
[1.2.14](rust-lang/cc-rs@cc-v1.2.13...cc-v1.2.14)
- 2025-02-14

###### Other

- Regenerate target info
([#1398](rust-lang/cc-rs#1398))
- Add support for setting `-gdwarf-{version}` based on RUSTFLAGS
([#1395](rust-lang/cc-rs#1395))
- Add support for alternative network stack io-sock on QNX 7.1 aarch64
and x86_64 ([#1312](rust-lang/cc-rs#1312))

</details>

[^dep-chain]: I think the dep chain is something like git2 ->
libgit2-sys -> curl -> curl-sys?
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

Successfully merging a pull request may close this issue.

3 participants