When compiling the libc crate with musl, don't look for libc.a #26302
Conversation
aidanhs
changed the title
| // When performing a cargo build with musl, we might not be able to find libc.a | ||
| // Fortunately, it's already been statically included in the liblibc archive. | ||
| #[cfg(all(target_env = "musl", feature = "cargo-build", not(test)))] | ||
| extern crate libc; |
There was a problem hiding this comment.
This unfortunately definitely needs to be left out because the liblibc library on crates.io needs to be able compile on stable Rust. I don't think this is necessary, however, because liblibc is included in the standard library which is transitively linked to this library, so this directive shouldn't be necessary I believe.
musl may not be available on the target user's machine, and even if it is, we may not be able to find it because of how static libraries are searched for. Instead, use the transitively included liblibc which includes libc.a.
aidanhs
force-pushed
the
aphs-fix-musl-libc
branch
from
026709c to
52862e4
Compare
|
I live on nightly rust so hadn't realised the unstable directive is a hard restriction on stable! Thanks for the advice, that does seem to work. Updated PR. |
musl may not be available on the target user's machine, and even if it is, we may not be able to find it because of how static libraries are searched for. Instead, use the liblibc archive created at rust compile time which already contains libc.a. --- To be honest, my brain is bending a bit at this point and I wonder if I'm doing something a bit stupid. Problem: building the libc crate with target musl. It says "could not find native static library `c`, perhaps an -L flag is missing?". Some pondering: the key problem is the way static archives are searched for (note that a musl build attempts to statically link to libc) - they aren't. There are three locations which are checked (including `$PREFIX/lib/rustlib/x86_64-unknown-linux-musl/lib`), but this does not include `$PREFIX/lib`...and it probably shouldn't - rustc is mimicking the way native lib generation works by forcing you to provide the path yourself. You can make it work `cargo rustc` with `-L native=/path/to/musl/lib`, but even if this went in a build script for the libc crate, it wouldn't work if musl isn't installed by the end user. I've sprinkled `not(test)` around but I've no idea if I've done it right. This patch allows `cargo build --target x86_64-unknown-linux-musl` to work on a crate with a dependency on libc, where the musl-enabled rust was compiled before this patch. I've not yet kicked off the long process to build a musl-enabled rust with this patch, so it might be broken there. Sorry for the rambling. r? @alexcrichton
|
💔 Test failed - auto-linux-64-nopt-t |
|
@bors: retry On Mon, Jun 15, 2015 at 9:00 AM, bors notifications@github.com wrote:
|
|
⚡ Previous build results for auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt are reusable. Rebuilding only auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt... |
musl may not be available on the target user's machine, and even if it is, we may not be able to find it because of how static libraries are searched for.
Instead, use the liblibc archive created at rust compile time which already contains libc.a.
To be honest, my brain is bending a bit at this point and I wonder if I'm doing something a bit stupid.
Problem: building the libc crate with target musl. It says "could not find native static library
c, perhaps an -L flag is missing?".Some pondering: the key problem is the way static archives are searched for (note that a musl build attempts to statically link to libc) - they aren't. There are three locations which are checked (including
$PREFIX/lib/rustlib/x86_64-unknown-linux-musl/lib), but this does not include$PREFIX/lib...and it probably shouldn't - rustc is mimicking the way native lib generation works by forcing you to provide the path yourself. You can make it workcargo rustcwith-L native=/path/to/musl/lib, but even if this went in a build script for the libc crate, it wouldn't work if musl isn't installed by the end user.I've sprinkled
not(test)around but I've no idea if I've done it right.This patch allows
cargo build --target x86_64-unknown-linux-muslto work on a crate with a dependency on libc, where the musl-enabled rust was compiled before this patch. I've not yet kicked off the long process to build a musl-enabled rust with this patch, so it might be broken there.Sorry for the rambling.
r? @alexcrichton