Looks for static musl despite -C target-feature=-crt-static

[vorner]

Hello

I'm not entirely sure the issue belongs in this repository, but it is where the problem manifests. Also, it might be something I do incorrectly. I apologize if it is so.

I have an SDK for an OpenWRT device, and the system is musl-based. If I compile with the usual armv7-unknown-linux-musleabihf, the result works, but it bundles its own statically liked copy of musl, which is not nice on embedded. Therefore, I'm attempting to use xargo and my own target config to produce a dynamically linked binary. AFAIK the recently stabilized -C target-feature=-crt-static should allow me doing that. However, for reasons I'm unable to track down, I still get this error about static library c when compiling the libc crate:

error: could not find native static library `c`, perhaps an -L flag is missing?

I made a repository which reproduces the problem: https://github.com/vorner/xcompile. When the ./build script is run, it downloads the SDK (unfortunately, that's 425MBs of download and 1.5GB unpacked :-( ) and runs the failing build.

As far as I understand the parameters, the command line of rustc should be correct and ask for dynamic linking:

rustc --crate-name libc /home/vorner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/rustc/libc_shim/../../liblibc/src/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 -C panic=abort -C metadata=920c148c4f0c8bc4 -C extra-filename=-920c148c4f0c8bc4 --out-dir /tmp/.private/vorner/xargo.07nyCJ4iQeip/target/arm-openwrt-linux-muslgnueabi/release/deps --target arm-openwrt-linux-muslgnueabi -L dependency=/tmp/.private/vorner/xargo.07nyCJ4iQeip/target/arm-openwrt-linux-muslgnueabi/release/deps -L dependency=/tmp/.private/vorner/xargo.07nyCJ4iQeip/target/release/deps --extern core=/tmp/.private/vorner/xargo.07nyCJ4iQeip/target/arm-openwrt-linux-muslgnueabi/release/deps/libcore-53a001eb41f8f158.rlib -Zincremental=/tmp/.private/vorner/xargo.07nyCJ4iQeip/target/arm-openwrt-linux-muslgnueabi/release/incremental -C target-feature=-crt-static --sysroot /home/vorner/.xargo -Z force-unstable-if-unmarked --cfg stdbuild

The rustc should be new enough, and the libc sources come from the same batch provided by rustup:

rustc 1.20.0-nightly (8d22af87d 2017-07-22)

I'd really like to track this down, but I have no idea where to look. I believe it is not related to this #685 and I don't think there's another place where to ask for dynamic crt.

Thank you

[alexcrichton]

The way this the crt-static feature is implemented it'll still need to find libc.a, it just won't use it as part of the end product. If you provide libc.a does it still end up working at the end?

[vorner]

That's a bit surprising behaviour O:-). If I asked how large a task it would be to make it not need that libc.a, and if I could get a pointer or two where to dig in the compiler code, would I regret it? I grepped a bit through the code, but it's huge and I don't have an idea about how the parts fit together. I want to start hacking on the compiler sometime.

Anyway, to answer the question, it helps (actually, libc.a was there to start with, but I was trying to pass -L to the linker, not to rustc). Now I get a step further, to missing libunwind. That one will probably take me a bit longer to solve, so I can't really confirm the end result just yet.

[alexcrichton]

At this point "make it not need libc.a" would be a change to the language essentially, so I think it's a bit beyond the scope of a bug fix int he compiler.

[vorner]

OK, I finally managed to compile it (with some other, unrelated problems). I can confirm the resulting binary is dynamically linked, so that thing works.

What do you mean by a change to the language? Do you mean from the user point of view? I think this would be OK, as the user obviously asks for a dynamic linkage and the only difference would be that it would fail before the fix and succeed after. Or, is there a use case I don't see for requiring the static library and then throwing it away later on?

Or do you mean the fix would be too complex and would require a language change for it to be possible?

[alexcrichton]

Oh I just mean that the semantics of the attribute are defined by the compiler, not by the libc crate. Any change to these semantics would require upstream work in rustc.

[vorner]

I see now this issue is opened on the wrong repository. Thanks for all the help, I'll try digging in the code a bit more or asking on #rust-internals if I can pin it down. If not, I'll open an issue in rustc.