Introduce RUSTC_STATIC_CLANG_RT_PATH and RUSTC_STATIC_UNWIND_PATH envs

[catap]

The goal of this envirements variable is easy statically link libclang_rt or libunwind into rust.

It also introduces a way to easy extend rust build in a way which allows to inject more static builds for some rare system if it required.

It haven't been documented because it seems as very deep hack and the user who needs it will discover this hack by reading sources ;)

Closes: #59164

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @davidtwco (or someone else) soon.

Please see the contribution instructions for more information.

[davidtwco]

This probably warrants a major change proposal as it adds a public-facing change (we'd have to support this environment variable going forwards).

[catap]

@davidtwco not sure to be honest. This is very low-level hack that allows to inject some dependency when it needed and can't be discovered by cross building.

Another approach is adding (a lot) if's inside build.rs or start to use such hack.

From my point of view this hack is the best possible way because if I rebuild it to target platform where libunwind isn't discovered automatically the first place to start digging how to hack it (for me) is build.rs for library/unwind where I've discovered it and enjoyed it :)

But, still, I may not understand and estimate right the long term cost of supporting it but from my point of view it nothing. Am I wrong?

[davidtwco]

I guess its more rustc developer/distribution-facing than user-facing, @Mark-Simulacrum do you know how we decide to add environment variables to build.rs for std/rustc?

[Mark-Simulacrum]

I agree this is distro/developer-facing. The requirement for adding this is mainly convincing someone, typically me or someone else familiar with our linking story (petrochenkov, often).

In this case, I'm not sure this is the right next step here -- can you elaborate on the motivation here? #59164 seems like a case where the library/crate being compiled should be including the library, rather than pushing for std to link it in.

libunwind already has llvm-libunwind option which, on some platforms, leads to a static link. clang_rt I don't think currently has such an option, but it seems plausible we could add it (rather than having an env variable ad-hoc providing that).

[JohnCSimon]

Ping from triage:
@catap can you please address the comment

In this case, I'm not sure this is the right next step here -- can you elaborate on the motivation here?

[catap]

@JohnCSimon, @Mark-Simulacrum the root cause of motivation for this changes is attempt to build rust which can be run on macOS before 10.7.

Anyway, it still requires a few things, and right now I haven't got any time to finish this build.

If it fine, keep this PR open for a while and as soon as I achived that, I'll update/rebase this one and open a few more which is required.

[bors]

☔ The latest upstream changes (presumably #94480) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnCSimon]

@Mark-Simulacrum - @catap has replied to your question

[Mark-Simulacrum]

I think if we're going to add configuration like this, it should go through config.toml and into the build scripts via rustbuild-set environment variables (or other means of passing configuration, perhaps existing ones).

For libunwind, it seems like we already try to support static linkage via crt-static and/or llvm-libunwind=in-tree. Maybe those options suffice here? If not, maybe this configuration should be gated on those rather than new configuration options?

[Dylan-DPC]

@catap any update on this pr? thanks

[JohnCSimon]

@catap
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you do please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive