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

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

Merged
merged 1 commit into from Jun 15, 2015

Conversation

@aidanhs
Copy link
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 When the libc crate with musl, don't look for libc.a When compiling the libc crate with musl, don't look for libc.a Jun 15, 2015
// 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.

Copy link
@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.

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 aidanhs force-pushed the aidanhs:aphs-fix-musl-libc branch from 026709c to 52862e4 Jun 15, 2015
@aidanhs
Copy link
Member Author

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
Copy link
Member

alexcrichton commented Jun 15, 2015

@bors: r+ 52862e4

Thanks!

@bors
Copy link
Contributor

bors commented Jun 15, 2015

Testing commit 52862e4 with merge d9b8015...

bors added a commit that referenced this pull request Jun 15, 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
@bors
Copy link
Contributor

bors commented Jun 15, 2015

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

@alexcrichton
Copy link
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
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
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.