When compiling the libc crate with musl, don't look for libc.a #26302

Merged
merged 1 commit into from Jun 15, 2015

Conversation

Projects
None yet
3 participants
@aidanhs
Member

aidanhs commented Jun 14, 2015

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

@aidanhs aidanhs changed the title from When the libc crate with musl, don't look for libc.a to When compiling the libc crate with musl, don't look for libc.a Jun 15, 2015

src/liblibc/lib.rs
+// 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;

This comment has been minimized.

@alexcrichton

alexcrichton Jun 15, 2015

Member

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.

@alexcrichton

alexcrichton Jun 15, 2015

Member

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.

When building libc crate with musl, don't look for libc.a
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

This comment has been minimized.

Show comment
Hide comment
@aidanhs

aidanhs Jun 15, 2015

Member

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.

Member

aidanhs commented Jun 15, 2015

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.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 15, 2015

Member

@bors: r+ 52862e4

Thanks!

Member

alexcrichton commented Jun 15, 2015

@bors: r+ 52862e4

Thanks!

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jun 15, 2015

Contributor

⌛️ Testing commit 52862e4 with merge d9b8015...

Contributor

bors commented Jun 15, 2015

⌛️ Testing commit 52862e4 with merge d9b8015...

bors added a commit that referenced this pull request Jun 15, 2015

Auto merge of #26302 - aidanhs:aphs-fix-musl-libc, r=alexcrichton
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
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jun 15, 2015

Contributor

💔 Test failed - auto-linux-64-nopt-t

Contributor

bors commented Jun 15, 2015

💔 Test failed - auto-linux-64-nopt-t

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 15, 2015

Member

@bors: retry

On Mon, Jun 15, 2015 at 9:00 AM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-linux-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-linux-64-nopt-t/builds/5321


Reply to this email directly or view it on GitHub
#26302 (comment).

Member

alexcrichton commented Jun 15, 2015

@bors: retry

On Mon, Jun 15, 2015 at 9:00 AM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-linux-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-linux-64-nopt-t/builds/5321


Reply to this email directly or view it on GitHub
#26302 (comment).

@bors bors merged commit 52862e4 into rust-lang:master Jun 15, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@aidanhs aidanhs deleted the aidanhs:aphs-fix-musl-libc branch Aug 21, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment