Require static native libraries when linking static executables

[smaeul]

gcc/ld will create a dynamically-linked executable without warning, even when passed -static, when asked to link to a .so. Avoid this confusing and unintended behavior by always using the static version of libraries when trying to link static executables.

This is a patch originally wrote as part of #40113. I was asked to hold off on it then. Now that I see others running into the same issue (#54243), and things have settled down a bit, I'm submitting it again.

This patch only affects musl and msvc (targets that set crt_static_respected). I don't know enough about msvc to know whether "static" binaries are any different than non-"static" ones in whether or not they can load DLLs. If they can load DLLs, then I'll need to add a !is_like_msvc check.

Note that this patch corresponds to one Alpine has been shipping since 1.16.0.

[rust-highfive]

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:2f35e68a:start=1541037063465106335,finish=1541037065498413215,duration=2033306880
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
travis_time:end:0053d52c:start=1541037075356955537,finish=1541037075370511011,duration=13555474
travis_fold:end:before_script.2
travis_time:start:153857fc
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Thu Nov  1 01:51:15 UTC 2018
Thu, 01 Nov 2018 01:51:15 GMT

The command "date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
" exited with 0.
travis_time:start:05189ae4

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[petrochenkov]

r? @alexcrichton

[alexcrichton]

Thanks for the PR! I think though that the naming here is a bit of a red herring, "NativeUnknown" is better to be named as "NativeDylib", as it comes up for kind = "dylib" as well.

With that in mind I'm not sure that this is quite the right patch, but rather it seems like we should emit a compiler error if a dynamically linked library is requested for a statically linked executable. That would itself be a breaking change I think, though, because the linker typically sorts things out where "ask for a dynamic library" is actually "just pass the right -l flag and most of the time it's static anyway".

Can you describe a bit more what's being fixed here? Is this largely just fixing a papercut? Or fixing a fundamental issue?

[smaeul]

Thanks for the PR! I think though that the naming here is a bit of a red herring, "NativeUnknown" is better to be named as "NativeDylib", as it comes up for kind = "dylib" as well.

If I write

#[link(name = "foo")]
extern {}

this will generate a NativeUnknown dependency. It's telling the compiler "link the most appropriate libfoo you can find". Are you telling me that writing

#[link(name = "foo", kind = "dylib")]
extern {}

will also generate a NativeUnknown dependency? If so, this is extremely counterintuitive behavior, because the second snippet is telling the compiler something completely different: "link libfoo, but only if you can find it as a shared library". Maybe I need to wire up a new NativeDylib choice?

With that in mind I'm not sure that this is quite the right patch, but rather it seems like we should emit a compiler error if a dynamically linked library is requested for a statically linked executable.

I wholeheartedly agree. Passing kind = "dylib" along with +crt-static should be an immediate compiler error. (Again, with the caveat that nothing I say applies to MSVC, as I have no idea how that works.)

That would itself be a breaking change I think, though, because the linker typically sorts things out where "ask for a dynamic library" is actually "just pass the right -l flag and most of the time it's static anyway".

Sorry, but this is just false. Everywhere but macOS (where you can't create static binaries anyway), GccLinker explicitly prevents the linker from choosing what kind of library to use, by passing it -Bdynamic or -Bstatic (called from here).

Moreover, the patch as written is not a breaking change (again, ignoring MSVC). As explained below, rustc today produces entirely nonfunctional binaries in the scenario this patch affects.

Can you describe a bit more what's being fixed here? Is this largely just fixing a papercut? Or fixing a fundamental issue?

Today, without this patch, it is impossible to link a native library into a static binary with either #[link(name = "foo")] extern {} or cargo:rustc-link-lib=foo. Instead, a completely broken binary is produced, and absolutely no warning or error is emitted at the time.

---

A recent example of this being a problem is #54243. This broke the entire testsuite in #55163 until they globally added RUSTFLAGS="-C target-feature=-crt-static" (search for "failed to exec"). There are plenty of other reports around the web. Try here, here, here, here, here, here, here, and also #39998. This was also an issue while developing #40113 (e.g. here). Quoting what I originally said there:

4. The current problem is that, when base.dynamic_linking = true, base.crt_static_default = true is not enough to enforce that binaries are statically linked by default.

   • It does not enforce that all linked libraries must also be statically linked, so when gcc sees dynamic libraries, it creates a dynamic executable (i.e. an ELF with DT_NEEDED entries).
   • But because you told it you were creating a static executable, gcc not pass -dynamic-linker to ld to add the correct PT_INTERP header to the ELF, and therefore ld uses its hardcoded default for the architecture, e.g. /lib/ld64.so.1 on x86_64.

5. Therefore, to maintain the status quo from 3 when setting base.dynamic_linking = true, we must first fix +crt-static, which is turned on by base.crt_static_default = true (regardless of any setting in config.toml), to actually do what it says. It should convert -lc -lgcc, etc. from linking dynamically to linking statically.

   • For GccLinker, this means changing them from being preceded by -Bdynamic to being preceded by -Bstatic, which is exactly the change I made to NativeLibraryKind::NativeUnknown.

To put this in to terms more relevant to today, if I compile an executable crate with target-features=+crt-static and cargo:rustc-link-lib=foo, here's what happens:

1. rustc builds a command line for gcc.
   • Because of target-features=+crt-static, -static is added to gcc's command line.
   • A NativeUnknown dependency is created on foo. That dependency is translated to -Wl,-Bdynamic -lfoo on the gcc command line in GccLinker::link_dylib().
2. rustc calls gcc, which interprets its arguments and builds a command line for ld.
   • Because -static was passed, gcc thinks a static binary is being generated. Static binaries don't have a dynamic linker, by definition. So gcc does not pass -dynamic-linker to ld. It does forward -static to ld.
   • gcc sees -Wl,-Bdynamic. It's an argument for gcc's linker backend, not the compiler driver, so gcc doesn't interpret it. It only strips off the -Wl and passes the rest to ld.
   • -lfoo is also forwarded to the linker.
3. gcc runs ld. ld's command line looks something like the following (along with a bunch of irrelevant arguments such as library paths and startup files):

   ld -static /tmp/$EXECUTABLE_CRATE.o -Bdynamic -lfoo -Bstatic $PATH_TO_LIBSTD -lc -lunwind
   

   • ld sees -static. Okay, we're making a static binary.
   • ld sees -Bdynamic. Wait a minute. You can't link dynamic libraries into a static binary. But you told me to link libfoo dynamically. So I guess we're making a dynamic binary now! (In other words ld completely ignores -static at this point).
   • ld sees -lfoo. If libfoo.so exists in a library search path, it gets linked; ld doesn't even look for libfoo.a if it finds a libfoo.so.
   • ld sees -Bstatic and goes back to looking for static libraries. It sees libstd, libc, and libunwind and links them all statically into the binary.
   • ld doesn't see -dynamic-linker, so since dynamic binaries must have one, it uses the hardcoded default, which on x86_64 is /lib/ld64.so.1 (this is leftover from the libc5 days, so it's very wrong even for glibc).
4. The build succeeds without any errors or diagnostic messages.
5. You try to run the resulting binary, and it fails to execute with "No such file or directory", because of course /lib/ld64.so.1 doesn't exist on your system. Even if the dynamic linker path was correct, the binary would segfault because it has two copies of libc's global data (locks, symbol and thread lists, etc.): one statically linked in, used by the main program; and one dynamically linked, used by the native shared libraries.

---

That's probably way more detail than you need, but I hope it's clear now that, yes, this is an issue; and yes, people are bitten by it on a regular basis.

There are three possible workarounds or "solutions" I'm aware of, in order of worst to best:

1. Stop passing -Bdynamic and -Bstatic hints to the linker. This allows the linker to choose the library type, but it also means kind="dylib" and kind="static-nobundle" (and no kind at all) do the exact same thing, and the developer loses control over which native dependencies are needed at runtime.
   • Note that keeping the hints everywhere except NativeUnknown is not possible. Once you pass -Bstatic (e.g. for NativeStatic), everything is static unless you later pass -Bdynamic. And -Bdynamic is what makes everything explode.
2. Prohbit NativeUnknown libraries from ever being linked into static executables. This forces every crate that wants to use native libraries to use kind="static" or kind="static-nobundle" (possibly with #cfg[target_feature("crt-static")]), or they will be unusable for static linking.
3. Interpret NativeUnknown as dynamic if the binary is dynamic, or static if the binary is static, like the patch in this PR. This is akin to how ld interprets a -l options with no preceding -B option. It works, it's intuitive, and it doesn't require patching hundreds of crates. As suggested above, we could add a NativeDynamic (or whatever you want to name it) option for kind="dylib" that always links dynamically, and produces an error on sess.crt_static() == true.

[smaeul]

@alexcrichton I read back through your conversation with @aidanhs in #40113 (which I probably should have done earlier), and I agree that I'll need to add NativeDylib or NativeDefault, however it's named, to distinguish kind="dylib" and no kind, before this would be mergeable.

"No kind always means dylib, even when impossible" is counterintuitive to me, but if that's the documented behavior, then this is a behavior change and not just a bugfix. So I should treat it more carefully as such. However, I'd like to reiterate what @aidanhs said that this is "a strictly non-breaking change" for musl.

[alexcrichton]

Unfortunately I think we're basically in a bind with omitting kind, it's always been documented that not specifying anything implies dylib as a kind. In that sense there's no way to add a NativeDylib type because it's already there, and NativeUnknown is still just a bad name.

I personally feel like this continues to pile on evidence that attempting to have the same target for both dynamically and statically linked musl is just the wrong strategy. There's already a few flags that need to be passed and configuration has to be just right across the entire stack to get things working. Misconfiguration leads to everyone feeling like the have to hack around everything when the fact of the matter is that the original musl target was simply never added with the intention of supporting both static and dynamic linking.

While I think you're right that this technically isn't a breaking change it doesn't really make sense to land in the model that we have today which is that you specify a library as either dynamic/static to link later. An alternative may be to just ignore linker library hints entirely on musl perhaps?

[smaeul]

To be fair, nothing about this issue is specific to musl. In fact, if you look at the patches downstream in various distributions, they remove all of the special flags and hacks that make musl targets complicated. We're just seeing this issue on musl because it's one of the very few libc implementations that fully supports both linkages. If you were able to create fully static glibc-linked binaries, you'd run into the exact same issue. So what I really don't want to do is make the musl targets even more special.

Unfortunately I think we're basically in a bind with omitting kind, it's always been documented that not specifying anything implies dylib as a kind. In that sense there's no way to add a NativeDylib type because it's already there, and NativeUnknown is still just a bad name.

Is it not possible to change the documentation? It seems like this is the only hangup. Or is there another issue with the semantics of "Implies dylib when compiling a dylib or normal binary, or static [or possibly static-nobundle] when compiling a static binary"? Remember that crt-static is a no-op everywhere but musl and MSVC already, so this has no functional impact on other targets. It does not require people to go around adding kind = "dylib" to any existing crates. Once again, this only affects people whose use cases are currently broken. I'd think the community would appreciate the new feature of "the compiler automatically picks the right library to link".

Actually, the documentation recommends to "inspect the resulting binary to ensure that it's linked as you would expect after the compiler succeeds." So yes, the behavior with respect to NativeUnknown is documented, but it's also documented that sometimes the compiler does the wrong thing.

I personally feel like this continues to pile on evidence that attempting to have the same target for both dynamically and statically linked musl is just the wrong strategy. There's already a few flags that need to be passed and configuration has to be just right across the entire stack to get things working. Misconfiguration leads to everyone feeling like the have to hack around everything when the fact of the matter is that the original musl target was simply never added with the intention of supporting both static and dynamic linking.

What would you even name the new target? Would you create a new target for static glibc? Then what is the point of crt-static?

While I think you're right that this technically isn't a breaking change it doesn't really make sense to land in the model that we have today which is that you specify a library as either dynamic/static to link later. An alternative may be to just ignore linker library hints entirely on musl perhaps?

Can we not fix the model?

[alexcrichton]

Also just to clarify, everything here is entirely my own personal opinion. Others who also help out in maintaining the compiler may feel radically different than I. Mine certainly isn't the only opinion that matters here!

These sorts of linkage questions are notoriously hard to change after the fact (which I feel like we've largely learned over time). Changes like this which originate from one platform tend to have far-reaching and unintended consequences on other platforms, often taking shape of situations that are uncovering other bugs or simply weren't thought of originally. I agree that this naively looks like it only would help to fix and/or change already broken code, but I in no way would say that with conviction.

The crt-static flag was primarily added for MSVC. IIRC after-the-fact it was attempted to repurpose the same flag for musl and whether or not libc is dynamically or statically linked. The behavior of statically linking libc on musl is quite different than what it means to have a static CRT on MSVC. That, plus the fact that everything has attempted to get shoehorned into one target, means that things are complicated and not always working today.

This is why I am personally a fan of adding new target, something like x86_64-alpine-linux-musl or something like that. Adding a new target means we can't regress other targets, and it's a chance to clean out old configuration eventually and make sure that code is updated to specifically handle just this one target, not other targets.

This PR, if interpreted literally, is wrong for MSVC. A static CRT doesn't mean you can't link to a dynamic library. This won't regress MSVC, however, because the implementation of link_staticlib and link_dylib looks exactly the same. If that were to change one day, however, it would produce bugs. This is one example of how a one-target-specific-problem which attempts to fix it for all targets can have unintended consequences.

I'd be curious to hear the thoughts of others on this topic, but historically there haven't been too many too interested in this topic. I'm personally trying to keep projects from regressing while ensuring we can still add new features and fix bugs in rustc, and I'm specifically worried about how a patch like this might accidentally affect someone's usage of the existing musl target or MSVC.

[corbinu]

@alexcrichton @smaeul Super happy to see all the things happening here! Just my two cents but I think having a target like x86_64-alpine-linux-musl or x86_64-linux-staticmusl would be a very cool idea.

I feel like a being able to easily build single static linux binary is a relevant target that people would like being able to just specify and go. I also think it has great implications for Rust's use with Serverless and Docker since that kind of binary can be inserted in a scratch docker container and not even need Alpine.

[awilfox]

If you are going to add an x86_64-alpine-linux-musl target, please also add the following for Adélie, which is a completely separate distribution from Alpine and has wildly different opinions on how things should be done:

• aarch64-foxkit-linux-musl
• armv5-foxkit-linux-musleabi
• armv6-foxkit-linux-muslgnueabihf
• mips-foxkit-linux-musl
• powerpc-foxkit-linux-musl
• powerpc64-foxkit-linux-musl
• i486-foxkit-linux-musl
• i586-foxkit-linux-musl
• x86_64-foxkit-linux-musl

Please also note that Alpine is only shipping Rust on x86_64, while we are already shipping it on all of our tier1 platforms (ppc32, ppc64, i586, x86_64) and will eventually be bringing it to tier2 platforms as possible (armv5/6, arm64, mips, i486). In fact, bringing Rust to our arm64 port was why I filed #54999.

Unlike Alpine we are focused on desktop usage and we feel Rust is very important to the future of the Linux desktop (Firefox, librsvg, and other Gnome projects being a small sample of what is to come).

I'm not sure what should be done for Void, since they have no vendor triplet that I'm aware of and they ship both glibc and musl versions of their distributions.

[alexcrichton]

@awilfox sorry that was just a strawman of what the target might look like! I didn't mean to single out Alpine. If a new target were added it'd likely more appropriately be named something like x86_64-dynamic-linux-musl or something generic like that. We don't have target per glibc-based distribution (aka ubuntu/debian/fedora/etc), we've just got one x86_64-unknown-linux-gnu that covers everything. Similarly all musl-based distributions should be able to use the same target

[mati865]

It'd be a bit confusing:

Dynamic	Static
x86_64-unknown-linux-gnu	x86_64-static-linux-gnu (if it's ever made)
x86_64-dynamic-linux-musl	x86_64-unknown-linux-musl

It'd more clear if targets were named like $arch-{dynamic,static}-linux-{gnu,musl}. For the backward compatibility unknown target would point to dynamic or static depending on the libc.

[alexcrichton]

@mati865 it'll likely be inconsistent, yes, but that's sort of a fact of life we'll have to live with because it's the way it is right now.

[malbarbo]

How about naming the static version?

Dynamic	Static
x86_64-unknown-linux-gnu	x86_64-static-linux-gnu (if it's ever made)
x86_64-unknown-linux-musl	x86_64-static-linux-musl

[alexcrichton]

@malbarbo that would unfortunately be a breaking change to the existing x86_64-unknown-linux-musl target, which we're not prepared to do

[TimNN]

Ping from triage @smaeul / @alexcrichton: What is the status of this PR? Is it blocked on something (RFC / FCP)?

[alexcrichton]

I personally still feel that this is too high risk to land, and that the best way forward here is to add a dedicated target for dynamically linking musl, something like x86_64-dynamic-linux-musl or x86_64-unknown-linux-dynmusl (or something like that)

[alexcrichton]

in that it's not blocked on FCP/RFC/etc, just a consensus about the direction to take

[smaeul]

So in that case do you suggest changing the current targets back to dynamic_linking = false? I think that should be sufficient to fix linkage issues. Would crt-static then be forced true or false for the static musl target (or ignored)? I'm thinking of its uses in #[cfg] in the wild moreso than how rustc uses it.

As for the dynamic musl target, would it support crt-static at all? Or would you prefer to make crt-static a MSVC-only thing?

I'm trying to clarify the semantics you're looking for, so maybe I can submit an updated patch. I agree it does reduce the differences between targets, so the only differentiating factor is dynamic_linking.

From a Linux distribution maintainer's perspective, it would be great if the dynamic musl target supported both static and dynamic linkage via crt-static. Otherwise, we'd have to ship two targets, with identical copies of all of the libraries, or do hacky things with symlinks to pretend to have both targets installed.

[alexcrichton]

Hm I'm not certain on those questions. If a new target is added and it supports both then the current one effectively becomes deprecated which would be pretty unfortunate. If a new one is added it doesn't necessarily mean we can tweak the existing one, though, lest we risk breaking changes to current usage. Thinking more about it, it may not be the best way forward?

I'm trying to think of how we can solve the problem here, and one thing I wanted to clarify was what motivated this patch? In the abstract it makes sense that this is problematic (asking for a dynamic library on a static musl target produces a weird binary). Is there like one or two concrete use cases we can fix up though? It seems that all crates.io crates should "already be correct" and libstd may be the culprit here, but I'd want to confirm

[mati865]

What about creating new target like x86_64-experimental-linux-musl or whatever else (actually having something different from -musl at the end would be nice because it would avoid current checks for musl) with purpose to be test ground for getting static and dynamic musl builds at same time.
Once it's works both as dynamic target and is at least as good in being static as current musl, all the changes would be moved to main musl target and experimental would be removed.

[frol]

I am not quite sure whether the following issue belongs here, but ...

I have an issue getting my project statically linked on Alpine:

$ env RUSTFLAGS='-C target-feature=+crt-static' cargo build
...
cannot produce proc-macro for `serde_derive v1.0.87` as the target `x86_64-alpine-linux-musl` does not support these crate types

I can successfully build it on Arch Linux using default target (glibc dynamic linking) and x86_64-unknown-linux-musl (static linking), and on Alpine Linux with their default target x86_64-alpine-linux-musl (dynamic linking).

Any hints?

[Centril]

@dpc what team is this waiting on?

[smaeul]

@Centril This PR is waiting on me to come up with a minimal reproducer for the issue that this PR is trying to solve. I hadn't gotten around to doing so because I package rust for all of the Linux distributions I use, so I don't have an unpatched/nightly rustc readily available. I can easily grab one now thanks to #58575, so I'll try to come up with something today.

[smaeul]

Ok, so coming up with a reproducer wasn't too hard. I picked the first example from the curl-rust README.

This is all done on a musl-based Linux distribution (gentoo), and I do not have the static versions of any of these libraries installed.

$ wget -nv -P /tmp https://static.rust-lang.org/dist/rust-nightly-x86_64-unknown-linux-musl.tar.gz
2019-03-30 12:30:11 URL:https://static.rust-lang.org/dist/rust-nightly-x86_64-unknown-linux-musl.tar.gz [207388273/207388273] -> "/tmp/rust-nightly-x86_64-unknown-linux-musl.tar.gz" [1]
$ tar xf /tmp/rust-nightly-x86_64-unknown-linux-musl.tar.gz -C /tmp
$ /tmp/rust-nightly-x86_64-unknown-linux-musl/install.sh --prefix=/tmp/rust-nightly
install: creating uninstall script at /tmp/rust-nightly/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'cargo'
install: installing component 'rustfmt-preview'
install: installing component 'llvm-tools-preview'
install: installing component 'rust-analysis-x86_64-unknown-linux-musl'
install: installing component 'rust-std-x86_64-unknown-linux-musl'

    Rust is ready to roll.

$ PATH=/tmp/rust-nightly/bin:$PATH
$ cargo -vV
cargo 1.35.0-nightly (0e35bd8af 2019-03-13)
release: 1.35.0
commit-hash: 0e35bd8af0ec72d3225c4819b330b94628f0e9d0
commit-date: 2019-03-13
$ rustc -vV
rustc 1.35.0-nightly (e782d790f 2019-03-29)
binary: rustc
commit-hash: e782d790f1b63d82af39248bebe027f92d891bcc
commit-date: 2019-03-29
host: x86_64-unknown-linux-musl
release: 1.35.0-nightly
LLVM version: 8.0
$ cargo new --bin linkage-bug
     Created binary (application) `linkage-bug` package
$ cd linkage-bug
$ echo 'curl = "0.4.20"' >> Cargo.toml
$ cat > src/main.rs << 'EOF'
> extern crate curl;
>
> use std::io::{stdout, Write};
>
> use curl::easy::Easy;
>
> // Print a web page onto stdout
> fn main() {
>     let mut easy = Easy::new();
>     easy.url("https://www.rust-lang.org/").unwrap();
>     easy.write_function(|data| {
>         stdout().write_all(data).unwrap();
>         Ok(data.len())
>     }).unwrap();
>     easy.perform().unwrap();
>
>     println!("{}", easy.response_code().unwrap());
> }
> EOF
$ cargo run
    Updating crates.io index
   Compiling semver-parser v0.7.0
   Compiling pkg-config v0.3.14
   Compiling libc v0.2.51
   Compiling cc v1.0.32
   Compiling cfg-if v0.1.7
   Compiling openssl-probe v0.1.2
   Compiling semver v0.9.0
   Compiling libz-sys v1.0.25
   Compiling curl-sys v0.4.17
   Compiling rustc_version v0.2.3
   Compiling openssl-sys v0.9.43
   Compiling socket2 v0.3.8
   Compiling curl v0.4.20
   Compiling linkage-bug v0.1.0 (/tmp/foo/linkage-bug)
    Finished dev [unoptimized + debuginfo] target(s) in 10.66s
     Running `target/debug/linkage-bug`
error: could not execute process `target/debug/linkage-bug` (never executed)

Caused by:
  No such file or directory (os error 2)
$ file target/debug/linkage-bug
target/debug/linkage-bug: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, with debug_info, not stripped

I built it again to show the linker args:

$ touch src/main.rs
$ RUSTFLAGS='-Z print-link-args' cargo build
   Compiling linkage-bug v0.1.0 (/tmp/foo/linkage-bug)
"cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-Wl,--eh-frame-hdr" "-m64" "-nostdlib" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/crt1.o" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o" "-L" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.15m67f4lijrk2kmm.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.162m8fin4il5iovi.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.17m81muic5ymvh63.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.1aqoxn3ty90dlrpe.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.1bqb1h0ih7hk46hk.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.1f1a7bwglebsc2j0.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.1fnczko38lstf45.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.1v3jvr4w4o9to3o3.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.1x2w9cqyxmlq014s.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.2dg8d30b5btqj36l.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.2dq3mgcbes4i213z.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.2h5ivs56lfmn9xvx.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.2ofout623ubrev3k.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.2slmwckpw87rsjue.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.3a1mdnx11aedupen.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.3g9d498rm2abke4t.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.4hxgxjf7eatx1c66.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.4ii7bj50s6mcm3cr.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.4mn9anqz72o78mjd.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.4ndq4tfbvmlf01bv.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.51iu7neeqk8msxg8.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.54iauuogb7j070nj.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.56xgojffm9u2d9jw.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.5g82imlzh8kyctqt.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.glacheq2grgh5h3.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.j06y0tbubp3tmfv.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.jofltkpljvphjp7.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.k6oajfbulfnwltn.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.l9307i32b9ns8k7.rcgu.o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.u8ct8g1ja29i14n.rcgu.o" "-o" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6" "/tmp/foo/linkage-bug/target/debug/deps/linkage_bug-8515ef78d2e327d6.1mdzrpnilaiiloho.rcgu.o" "-Wl,--gc-sections" "-no-pie" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/tmp/foo/linkage-bug/target/debug/deps" "-L" "/usr/lib" "-L" "/usr/lib" "-L" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib" "-Wl,-Bstatic" "/tmp/foo/linkage-bug/target/debug/deps/libcurl-d49997a6f4108f3d.rlib" "/tmp/foo/linkage-bug/target/debug/deps/libopenssl_probe-de3c2a56f5a03bc7.rlib" "/tmp/foo/linkage-bug/target/debug/deps/libsocket2-85038c1da7d16bd8.rlib" "/tmp/foo/linkage-bug/target/debug/deps/libcfg_if-1b5a1417bb6c33aa.rlib" "/tmp/foo/linkage-bug/target/debug/deps/libcurl_sys-46f40a16606e3983.rlib" "/tmp/foo/linkage-bug/target/debug/deps/libopenssl_sys-c13864e6f82dcb29.rlib" "/tmp/foo/linkage-bug/target/debug/deps/liblibz_sys-4ade5aa497d796a3.rlib" "/tmp/foo/linkage-bug/target/debug/deps/liblibc-8588740f81bd49b8.rlib" "-Wl,--start-group" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0c4f6012505a64ae.rlib" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ff29f889cb57b5b6.rlib" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-b3e53f8e9f58cb0d.rlib" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-2bc5c9c36bf4533a.rlib" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-ab23897a9a0c444b.rlib" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-5f067c62510edb37.rlib" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-7d38043a47a71b82.rlib" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-8f4dba2468f32197.rlib" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-1b9655321933a544.rlib" "-Wl,--end-group" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-64a0a8f9d3310074.rlib" "-Wl,-Bdynamic" "-lcurl" "-lssl" "-lcrypto" "-lz" "-static" "/tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o"
    Finished dev [unoptimized + debuginfo] target(s) in 0.36s

Here's a cleaned-up version of the linker args (LTO and quotes removed):

cc -Wl,--as-needed -Wl,-z,noexecstack -Wl,--eh-frame-hdr -m64 -nostdlib \
    /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/crt1.o \
    /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/crti.o \
    /tmp/foo/linkage-bug/target/debug/deps/linkage_bug.o \
    -Wl,--gc-sections -no-pie -Wl,-zrelro -Wl,-znow -nodefaultlibs \
    -L /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib \
    -L /tmp/foo/linkage-bug/target/debug/deps -L /usr/lib \
    -Wl,-Bstatic \
    /tmp/foo/linkage-bug/target/debug/deps/libcurl-d49997a6f4108f3d.rlib \
    /tmp/foo/linkage-bug/target/debug/deps/libopenssl_probe-de3c2a56f5a03bc7.rlib \
    /tmp/foo/linkage-bug/target/debug/deps/libsocket2-85038c1da7d16bd8.rlib \
    /tmp/foo/linkage-bug/target/debug/deps/libcfg_if-1b5a1417bb6c33aa.rlib \
    /tmp/foo/linkage-bug/target/debug/deps/libcurl_sys-46f40a16606e3983.rlib \
    /tmp/foo/linkage-bug/target/debug/deps/libopenssl_sys-c13864e6f82dcb29.rlib \
    /tmp/foo/linkage-bug/target/debug/deps/liblibz_sys-4ade5aa497d796a3.rlib \
    /tmp/foo/linkage-bug/target/debug/deps/liblibc-8588740f81bd49b8.rlib \
    -Wl,--start-group \
        /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-0c4f6012505a64ae.rlib \
        /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libpanic_unwind-ff29f889cb57b5b6.rlib \
        /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libbacktrace_sys-b3e53f8e9f58cb0d.rlib \
        /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_demangle-2bc5c9c36bf4533a.rlib \
        /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-ab23897a9a0c444b.rlib \
        /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/liblibc-5f067c62510edb37.rlib \
        /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/liballoc-7d38043a47a71b82.rlib \
        /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/librustc_std_workspace_core-8f4dba2468f32197.rlib \
        /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libcore-1b9655321933a544.rlib \
    -Wl,--end-group \
    /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/libcompiler_builtins-64a0a8f9d3310074.rlib \
    -Wl,-Bdynamic \
    -lcurl -lssl -lcrypto -lz \
    -static \
    /tmp/rust-nightly/lib/rustlib/x86_64-unknown-linux-musl/lib/crtn.o

Because the program was linked with the static versions of crt*.o and libc.a, it's not a valid dynamic executable, even though file says it is "dynamically linked". So even if I run it via ld.so directly, it crashes:

$ /lib/ld-musl-x86_64.so.1 target/debug/linkage-bug
thread panicked while processing panic. aborting.
Illegal instruction

Of course, what we want in this case is a static executable, because that's the default for x86_64-unknown-linux-musl. To highlight, this is the breakage in the linker command line:

    -Wl,-Bdynamic \
    -lcurl -lssl -lcrypto -lz \
    -static \

We told cc to generate a static executable, but then we went behind it's back and told ld to add dynamic DT_NEEDED entries.

With this patch, we don't pass -Wl,-Bdynamic before the -l arguments, and I get the expected linker error:

  = note: /usr/lib/gcc/x86_64-gentoo-linux-musl/8.3.0/../../../../x86_64-gentoo-linux-musl/bin/ld: cannot find -lcurl
          /usr/lib/gcc/x86_64-gentoo-linux-musl/8.3.0/../../../../x86_64-gentoo-linux-musl/bin/ld: cannot find -lssl
          /usr/lib/gcc/x86_64-gentoo-linux-musl/8.3.0/../../../../x86_64-gentoo-linux-musl/bin/ld: cannot find -lcrypto
          /usr/lib/gcc/x86_64-gentoo-linux-musl/8.3.0/../../../../x86_64-gentoo-linux-musl/bin/ld: cannot find -lz
          collect2: error: ld returned 1 exit status

[smaeul]

As for how we go about fixing the breakage...

@alexcrichton apparently it's been so long that I completely forgot about it, but there's already a crt_static_allows_dylibs target option, which is true for MSVC and false for musl. So I could add

&& !sess.target.target.options.crt_static_allows_dylibs

to the check, which would fix/sidestep the whole MSVC issue and be more semantically meaningful anyway. It would also match the case here already in the code. With that chage, would this patch then become acceptable?

Then the impact of this change would be as follows:

• Targets with crt_static_respected = false or crt_static_allows_dylibs = true, i.e. all non-musl targets, would have no impact.
• musl targets with target-feature=-crt-static would also have no impact.
• musl targets without target-feature=-crt-static would only be affected in cases where they are currently producing broken binaries. The change would be to instead produce a functioning binary (in the case the static version of the library exists) or to produce a linker error (if the static binary is missing).

[alexcrichton]

I would personally still find it weird that rustc is trying to paper over mistakes in crates (aka you ask for a dylib and rustc just ignores that and links something else anyway). It probably has less breakage, but I honestly can't keep paging all this context back in once a month and keep up with this. At this point I think you'll just need to work with the release team to keep an eye out for breakage and be ready to revert, I'd personally prefer to step away from reviewing this change and have someone else review it.

[smaeul]

I pushed an update, for posterity if nothing else. I agree that there's a lot of nuance here that I'm missing as well, since the time I have available to work on this is so sporadic. I apologize for dragging you through this mess.

From your last comment, and the context in the code, I'm beginning to agree that this isn't the right fix. With the semantics of "NativeUnknown means dylib", this situation really should be an error. The user has asked the compiler to make a static executable, and also depend on a dylib, and those are mutually incompatible. The code I mentioned Saturday already does this for direct dependencies. So maybe it's better to check and reject the "rlib depends on a native dylib" case there as well?

I don't know enough about the code to write that patch, nor the time to dig in, so I'm going to close this PR and somebody interested can pick it up, whatever the solution ends up being.