Skip to content

fix: Remove forcing static builds when cross-compiling #244

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

Merged
merged 1 commit into from
Jul 4, 2025

Conversation

polarathene
Copy link
Contributor

This constraint is no longer necessary, due to improvements since it's original introduction in Feb 2016.

The zlib library will be linked dynamically (provided no explicit opt-in to static link) or fallback to building from source.


More details with discussion/history is covered here: #206 (comment)

Notably:

  • A project should not link zlib both dynamically (via another crate linking system deps that bring in zlib) and statically (vendored via libz-sys): Link against shared zlib library when cross-compiling #201
  • Building a target as a native arch or cross-compiled arch should not cause linking between dynamic vs static to occur when zlib is discoverable to link dynamically.

This PR ensures building for the target is consistent across correctly configured build environments.

This constraint is no longer necessary, due to improvements since it's original introduction in Feb 2016.

The zlib library will be linked dynamically (provided no explicit opt-in to static link) or fallback to building from source.
Copy link
Member

@Byron Byron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for sorting this out!

I agree that despite this affecting and possibly breaking downstream cross-compilations, people who need static builds can just opt back into it. Otherwise, it's better to not have a special case here, anymore.

@Byron Byron merged commit 1c2c7b0 into rust-lang:main Jul 4, 2025
48 checks passed
@polarathene
Copy link
Contributor Author

I have another PR to contribute as a follow-up, but have realized it'll be less effective than I thought it'd be as rustc / Cargo behave a bit unexpectedly.

This PR that was merged will most likely affect those cross-compiling to musl from glibc if they did not use the static feature or equivalent ENV. I think that is ok as it's not uncommon to run into linking issues when building crates like that, but some crates do seem to detect musl target and treat it as build from source.

Either way, without a common ENV supported across crates, I think the concern is tricky to satisfy everyone 😓

@Byron
Copy link
Member

Byron commented Jul 6, 2025

Thanks for the heads-up!

I think that is ok as it's not uncommon to run into linking issues when building crates like that, but some crates do seem to detect musl target and treat it as build from source.

Do you have a prominent example for that? Maybe a big part of the downstream disruption could be averted if this crate would do something similar, based on what an established crate is already doing?

Thanks again.

@polarathene
Copy link
Contributor Author

polarathene commented Jul 6, 2025

Do you have a prominent example for that?

I noticed the pcre2-sys crate has done this, with the PR linked providing an opt-out via ENV for those that want to prevent that (those packaging for musl distributions where dynamic linking is desired).

My only concern with that approach is the more sys crates involved, the larger a growing list of ENV to opt-out would be for those affected. It would be similar for the opposite scenario of those wanting to always enforce static linking though, so the broader audience to support for the convenience of reduced ENV requirements is cross compiling to musl targets implies static by convention in Rust?

Another crate libpng-sys detects static and always builds instead of linking to a prebuilt .a static archive because in 2019 a user reported a build failure as the static library they had to link on CentOS 7 wasn't compiled with -fPIC, however there was a misunderstanding as this is not required by Rust to link for an executable the relocation model just needed to change from default PIC to static.


It's possible unify static preference via an explicit RUSTFLAGS='-C target-feature=+crt-static' (the opposite -crt-static however is not, and it is not possible to detect an implicit +crt-static either with targets like musl, thus not entirely consistent). Which is an approach I implemented in my PR prior to discovering it wasn't detected implicitly with musl targets.

Rust also has -C prefer-dynamic=no as a code-gen option I think, but I'd need to look into that and not entirely sure how useful it'd be in a build.rs script if it can't be detected 🤔 (EDIT: Nope that's the default, and -C prefer-dynamic=yes seems to dynamic link rlibs like rusts libstd 😬)

As soon as I find some extra time I'll open a PR within the next day with what I had done so far and figure out a way forward from there 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants