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

Please see the contribution instructions for more information.

Is this environment variable standard (e.g., read by cmake itself or something?) -- otherwise, I would prefer that if it needs to be configured, we do so via config.toml rather than an ad-hoc environment variable.

@Mark-Simulacrum nope, it isn't a standard environment variable. Let me move to config when.

@Mark-Simulacrum like this?

Can you say more about the motivation for this? It looks like the intent is to use it to bootstrap on old (and no longer supported) systems, but there I would expect that you can place libtool in PATH and that should work well?

Since such systems will likely need a bunch of other patches applied to the rustc src tree anyway to enable successful builds, it's not clear to me this adds value -- and exposing an option generally not used seems like it adds complexity for all users, so I would prefer to avoid doing so.

@Mark-Simulacrum yes, you're right that I'm trying to make rust works on old system. In my case it is macOS 10.6.

My goal is quite simple: bring rust to old macOS via MacPorts. MacPorts provides a lot of modern software to old system which includes modern clang :)

Why? Because rust is starting to be popular platform to write new software. For example mozjs.

Right now I've bring a bit old rust (1.42) to macOS 10.6 and I'm just bootstrapping it one-by-one, it requires some time :)

Patch? Yes, I needed it but it is releativle small. Differences with rustc-1.42.0-src is:

24 files changed, 125 insertions(+), 15 deletions(-)

My sense is that if you need to adjust a bunch of llvm building opts, it probably makes sense to build llvm out of tree and specify it with llvm-config - that'll let you configure more freely, and without as much pain trying to pipe options through here.

I'm going to close this in favor of #93756. Thanks!