Force all native libraries to be statically linked when linking a static binary

[Amanieu]

Previously, #[link] without an explicit kind = "static" would confuse the linker and end up producing a dynamically linked library because of the -Bdynamic flag. However this binary would not work correctly anyways since it was linked with startup code for a static binary.

This PR solves this by forcing all native libraries to be statically linked when the output is a static binary that cannot link to dynamic libraries anyways.

Fixes #108878
Fixes #102993

[rustbot]

r? @compiler-errors

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

[WhyNotHugo]

I'm not entirely sure how to test this.

Given the original issue at hand here, I don't expect that I'll be able to use the nightly compiler to compile this branch.

I tried anyway, but:

> ./x.py setup --verbose
downloading https://static.rust-lang.org/dist/2023-04-20/rust-std-beta-x86_64-unknown-linux-musl.tar.xz
############################################################################################################################## 100.0%
downloading https://static.rust-lang.org/dist/2023-04-20/rustc-beta-x86_64-unknown-linux-musl.tar.xz
############################################################################################################################## 100.0%
downloading https://static.rust-lang.org/dist/2023-04-20/cargo-beta-x86_64-unknown-linux-musl.tar.xz
############################################################################################################################## 100.0%
extracting /home/hugo/src/github.com/rust-lang/rust/build/cache/2023-04-20/rust-std-beta-x86_64-unknown-linux-musl.tar.xz
extracting /home/hugo/src/github.com/rust-lang/rust/build/cache/2023-04-20/rustc-beta-x86_64-unknown-linux-musl.tar.xz
extracting /home/hugo/src/github.com/rust-lang/rust/build/cache/2023-04-20/cargo-beta-x86_64-unknown-linux-musl.tar.xz
Building bootstrap
   Compiling libc v0.2.140
   Compiling proc-macro2 v1.0.56
   Compiling memchr v2.5.0
   Compiling unicode-ident v1.0.0
   Compiling quote v1.0.26
   Compiling cfg-if v1.0.0
   Compiling version_check v0.9.4
   Compiling typenum v1.15.0
   Compiling bitflags v1.3.2
   Compiling io-lifetimes v1.0.9
   Compiling cc v1.0.73
   Compiling regex-automata v0.1.10
   Compiling serde v1.0.137
   Compiling pkg-config v0.3.25
   Compiling log v0.4.17
   Compiling lazy_static v1.4.0
   Compiling rustix v0.37.6
   Compiling once_cell v1.12.0
   Compiling clap_lex v0.4.1
   Compiling syn v1.0.102
   Compiling anstyle v1.0.0
   Compiling linux-raw-sys v0.3.2
   Compiling heck v0.4.1
   Compiling crossbeam-utils v0.8.14
   Compiling regex-syntax v0.6.26
   Compiling serde_json v1.0.81
   Compiling same-file v1.0.6
   Compiling serde_derive v1.0.137
   Compiling fnv v1.0.7
   Compiling clap_builder v4.2.4
   Compiling semver v1.0.17
   Compiling thread_local v1.1.4
   Compiling walkdir v2.3.2
   Compiling ryu v1.0.10
   Compiling cpufeatures v0.2.5
   Compiling bootstrap v0.0.0 (/home/hugo/src/github.com/rust-lang/rust/src/bootstrap)
   Compiling itoa v1.0.2
   Compiling build_helper v0.1.0 (/home/hugo/src/github.com/rust-lang/rust/src/tools/build_helper)
   Compiling termcolor v1.2.0
   Compiling generic-array v0.14.5
   Compiling hex v0.4.3
   Compiling cmake v0.1.48
   Compiling aho-corasick v0.7.18
   Compiling bstr v0.2.17
   Compiling object v0.29.0
   Compiling lzma-sys v0.1.17
   Compiling syn v2.0.15
   Compiling opener v0.5.0
   Compiling block-buffer v0.10.2
   Compiling crypto-common v0.1.3
   Compiling digest v0.10.3
   Compiling regex v1.5.6
   Compiling sha2 v0.10.2
   Compiling filetime v0.2.16
   Compiling xattr v0.2.3
   Compiling xz2 v0.1.6
   Compiling tar v0.4.38
   Compiling globset v0.4.8
   Compiling ignore v0.4.18
   Compiling toml v0.5.9
   Compiling is-terminal v0.4.6
   Compiling fd-lock v3.0.11
   Compiling clap_derive v4.2.0
   Compiling clap v4.2.4
   Compiling clap_complete v4.2.2
    Finished dev [unoptimized] target(s) in 0.03s
running: /home/hugo/src/github.com/rust-lang/rust/build/bootstrap/debug/bootstrap setup --verbose
finding compilers
CC_x86_64-unknown-linux-musl = "cc"
CFLAGS_x86_64-unknown-linux-musl = ["-ffunction-sections", "-fdata-sections", "-fPIC", "-m64", "-static"]
CXX_x86_64-unknown-linux-musl = "c++"
CXXFLAGS_x86_64-unknown-linux-musl = ["-ffunction-sections", "-fdata-sections", "-fPIC", "-m64", "-static"]
AR_x86_64-unknown-linux-musl = "ar"
verifying /home/hugo/src/github.com/rust-lang/rust/build/cache/2023-04-21/rustfmt-nightly-x86_64-unknown-linux-musl.tar.xz
extracting /home/hugo/src/github.com/rust-lang/rust/build/cache/2023-04-21/rustfmt-nightly-x86_64-unknown-linux-musl.tar.xz to /home/hugo/src/github.com/rust-lang/rust/build/x86_64-unknown-linux-musl/rustfmt
Traceback (most recent call last):
  File "/home/hugo/src/github.com/rust-lang/rust/./x.py", line 32, in <module>
    bootstrap.main()
  File "/home/hugo/src/github.com/rust-lang/rust/src/bootstrap/bootstrap.py", line 1084, in main
    bootstrap(args)
  File "/home/hugo/src/github.com/rust-lang/rust/src/bootstrap/bootstrap.py", line 1059, in bootstrap
    run(args, env=env, verbose=build.verbose, is_bootstrap=True)
  File "/home/hugo/src/github.com/rust-lang/rust/src/bootstrap/bootstrap.py", line 184, in run
    raise RuntimeError(err)
RuntimeError: failed to run: /home/hugo/src/github.com/rust-lang/rust/build/bootstrap/debug/bootstrap setup --verbose

Indeed, it looks like the root cause of this build failure is the same issue that this patch is trying to fix:

> /home/hugo/src/github.com/rust-lang/rust/build/bootstrap/debug/bootstrap setup --verbose
finding compilers
CC_x86_64-unknown-linux-musl = "cc"
CFLAGS_x86_64-unknown-linux-musl = ["-ffunction-sections", "-fdata-sections", "-fPIC", "-m64", "-static"]
CXX_x86_64-unknown-linux-musl = "c++"
CXXFLAGS_x86_64-unknown-linux-musl = ["-ffunction-sections", "-fdata-sections", "-fPIC", "-m64", "-static"]
AR_x86_64-unknown-linux-musl = "ar"
verifying /home/hugo/src/github.com/rust-lang/rust/build/cache/2023-04-21/rustfmt-nightly-x86_64-unknown-linux-musl.tar.xz
extracting /home/hugo/src/github.com/rust-lang/rust/build/cache/2023-04-21/rustfmt-nightly-x86_64-unknown-linux-musl.tar.xz to /home/hugo/src/github.com/rust-lang/rust/build/x86_64-unknown-linux-musl/rustfmt
zsh: segmentation fault  /home/hugo/src/github.com/rust-lang/rust/build/bootstrap/debug/bootstrap setup

This makes me wonder: how are official binaries produced if the upstream binaries aren't linking libraries properly? Is some non-default flag used when building these?

I guess I need to explicitly tell the nightly compiler to dynamically link to libc, right? Or statically link all external libraries?

[nekopsykose]

@WhyNotHugo that looks unrelated, i would assume you get that issue building the compiler without these changes. you'll have to figure out how to do that first

@Amanieu

before:

$ RUSTFLAGS="-Ctarget-feature=+crt-static" cargo build --release 
   Compiling libc v0.2.144
   Compiling memmap2 v0.5.10
   Compiling xkbcommon v0.5.0
   Compiling x v0.1.0 (/tmp/mytemp.iKnNJK/x)
    Finished release [optimized] target(s) in 3.53s
$ file target/release/x                                                           
target/release/x: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=221da58c22e8613b8972fe45c140e1c66396699c, with debug_info, not stripped
$ ./target/release/x       
zsh: segmentation fault (core dumped)  ./target/release/x

after:

first, building without a .a available fails (good):

  = note: /usr/lib/gcc/x86_64-alpine-linux-musl/13.1.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lxkbcommon: No such file or directory
          collect2: error: ld returned 1 exit status

adding the .a:

$ RUSTFLAGS="-Ctarget-feature=+crt-static" cargo build --release
   Compiling x v0.1.0 (/tmp/mytemp.iKnNJK/x)
    Finished release [optimized] target(s) in 2.96s
$ file target/release/x
target/release/x: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, BuildID[sha1]=f1dc0a1ca6ee75bb3b96ab24bdeacf82379f1305, with debug_info, not stripped
$ ./target/release/x       
Hello, world!

looks good!

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[petrochenkov]

r? @petrochenkov
I need to look at what this PR does in detail, probably next week.
There's some history behind these issues #71647, #39998, maybe #71651.

[Amanieu]

A static binary literally cannot link to dynamic libraries. The only sane behavior here is to force all external libraries to also be statically linked or to emit an error.

[petrochenkov]

A static binary ...

First, -C target-feature=+crt-static is more like "link libc statically" which is very similar to "make a static binary" on Unix-like targets, but e.g. on Windows you can link libc statically and still link to other DLLs because dynamic linker is an OS component and not libc component in that case.

... literally cannot link to dynamic libraries

Second, this is true for ELFs loaded by standard dynamic linker, but not necessarily true for ELF plugins loaded by something else.

For example, unix style linkers not being opinionated in this regard make it very convenient to make statically linked DynamoRIO plugins (with which you are probably familiar due to your work on MAMBO) that still link to libdynamorio.so dynamically at static link time and are loaded by that same libdynamorio.so instead of a standard ld.so.

[petrochenkov]

Sorry, no conclusion so far, I still didn't have time to devote to this PR properly.
But I wrote a very pedantic overview of linking libc and dynamic libraries on various targets a couple of years ago, which I need to re-read myself and which had some conclusions, possibly slightly over-engineered.

[petrochenkov]

I think we can try flipping the default for NativeLibKind::Unspecified libs only, while still respecting explicit dylib kinds to cover rare cases.

And land this on nightly only to see what breaks on targets that are more similar to Windows than to Linux.

[petrochenkov]

And run crater, although I don't expect it showing anything on Linux.
Too bad there's no Windows-based infra for crater.
@bors try

[petrochenkov]

@bors try

[bors]

⌛ Trying commit a93a806a16d2adb2984ee433cef0723472421de8 with merge c38f3f86763ea281f7c555c13ef11baad4a4fff4...

[bors]

☀️ Try build successful - checks-actions
Build commit: c38f3f86763ea281f7c555c13ef11baad4a4fff4 (c38f3f86763ea281f7c555c13ef11baad4a4fff4)

[petrochenkov]

@craterbot run mode=build-only

[craterbot]

👌 Experiment pr-111698 created and queued.
🤖 Automatically detected try build c38f3f86763ea281f7c555c13ef11baad4a4fff4
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-111698 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-111698 is completed!
📊 56 regressed and 7 fixed (285604 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[Amanieu]

@bors r=petrochenkov

[bors]

📌 Commit 0304e0a has been approved by petrochenkov

It is now in the queue for this repository.

[petrochenkov]

The previous wording was right in the sense that -Bdynamic with ld-like linkers is only a preference for a dynamic library, not a requirement, so a static library can be linked even despite kind=dylib if there's no dynamic version of it.

That's what I called "too platform specific" above.
That's why I also suggested to document things in terms of the inferred kind and not in terms of actually linked libraries.

[Amanieu]

Based on my experiments, this isn't actually a preference: the linker will not search for static libraries if -Bdynamic is specified.

[bors]

⌛ Testing commit 0304e0a with merge f383703...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing f383703 to master...

[rust-timer]

Finished benchmarking commit (f383703): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.4%	[0.4%, 0.4%]	2
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.3%	[-0.3%, -0.3%]	1

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 648.482s -> 649.083s (0.09%)