libc test builds two different versions of libc

[jessicah]

cd /Development/source/libc/libc-test
cargo test

In output:

Compiling libc v0.2.142
...
Compiling libc v0.2.142 (/Development/source/rust/libc)

At least on Haiku, this causes a linking error as the current libc on crates.io hasn't been updated with a fix to a linking issue, which has been fixed in my local repo (and has landed here, a new release hasn't been cut yet).

[JohnTitor]

0.2.143 will fix this.

[jessicah]

Ah, I have more changes to make to the libc crate, but need to be able to test properly. Is there no way for cargo test to use the local libc instead of from crates.io?

[JohnTitor]

I'm not sure if I understand your argument correctly, but wouldn't just cloning the repo and running the test on it be sufficient?

Like:

libc = { path = "../libc" }
# or, if you prefer using a remote repo
libc = { git = "https://your-fork/your-remote-repo.git" }

[jessicah]

in libc/libc-test/Cargo.toml:

[dependencies.libc]
path = ".."
version = "0.2.142"
default-features = false

But during build, I'm assuming some dependency is pulling in libc, and cargo downloads a copy from crates.io, instead of using libc in the parent directory. Hence why when running cargo test, I get a link failure due to not using the local libc.

Is the libc-test sub-directory not meant to be used directly for cargo test?

[JohnTitor]

You have to add them under [patch.crates-io]. See https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html if you're new to Cargo, it's quite helpful :)

[jessicah]

I tried that in the sub directory, but it seemed to have no effect. Is that maybe because it's part of a workspace?

[JohnTitor]

I don't have your workspace and cannot provide further directions, unfortunately :( I'd suggest reading the above docs more and investigating further (also, I think it's not a libc issue anymore but Cargo's usage).