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

rustc should prefer statically linking native dependencies with unspecified kind if crt-static is enabled #71647

Open
petrochenkov opened this issue Apr 28, 2020 · 6 comments
Assignees
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@petrochenkov
Copy link
Contributor

petrochenkov commented Apr 28, 2020

The main goal of +crt-static (at least on non-Windows targets) is to produce self-contained statically linked executables.

With this goal in mind rustc switches linking of 1) Rust crates and 2) libc to static if possible. (The libc part is done in the libraries through lazy cfgs though.)
However, for native dependencies with unspecified kind rustc will still prefer the dynamic version of the library if both are available.

Unfortunately, doing this is not entirely trivial because -Bstatic -lmylib won't just prefer the static version (e.g. libmylib.a), it will require it.
So we need to check for the existence of libmylib.a first (in which directories exactly?) and then pass -l:libmylib.a instead of -lmylib if it exists.

cc #71586 #39998

@petrochenkov petrochenkov added C-bug Category: This is a bug. A-linkage Area: linking into static, shared libraries and binaries labels Apr 28, 2020
@petrochenkov
Copy link
Contributor Author

petrochenkov commented Apr 28, 2020

-Bstatic -lmylib won't just prefer the static version (e.g. libmylib.a), it will require it.

If #39998 is accepted as the way to go by default when crt-static is enabled (on non-Windows platforms), then we can just use -Bstatic.

@jonas-schievink jonas-schievink added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 28, 2020
@smaeul
Copy link
Contributor

smaeul commented May 2, 2020

This was discussed at length in #55566, where I was told that NativeUnknown means dynamic, and changing the semantics of #[link] was unacceptable.

@petrochenkov
Copy link
Contributor Author

Some history in links: #71586 (comment)

@petrochenkov
Copy link
Contributor Author

@smaeul
I do not agree with what alexcrichton said #55566, it's mostly a "it mostly works, so don't touch it because you may break something" position motivated by lack of resources and people ready to take responsibilities for this work on the Rust side.

We can at least make an experiment (possibly using crater, possibly landing this on nightly and reverting) and verify what actually breaks in practice.

@nagisa
Copy link
Member

nagisa commented Mar 8, 2021

I fear crater will likely have a pretty poor coverage as far as linkage is concerned as its environment won't generally have anything but the most common libraries installed on the system (and the "native" libraries built in build.rs are already almost universally statically linked).

@polarathene
Copy link

Was this not resolved with #111698 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants