x.py has usability issues

[mccakit]

Please add the ability to pass RUSTFLAGS (or equivalent) to targets when using x.py. Right now, the only way is to pass environment variables, and even then it straight-up ignores them sometimes.

It also does weird stuff with copying files from the sysroot or failing with missing CRT files that I don't understand. Why does building Rust itself and cross-compiling the standard library work this way?

Clang is the linker, and I want to pass arguments per-target: --sysroot, include dirs, library dirs, etc., and just build. But no. x.py literally rebuilds the compiler every time I try to build the standard library, even if I tell it in bootstrap.toml to just use my existing rustc.

People literally embed Rust dependencies into C/C++ or Python projects. Why is this workflow (installing from source) so different?

I will not use binary distributions. Platform defaults aren’t always the same. I don’t want to rely on libstdc++ or gcc_s for Linux builds. I just want: target-specific flags + existing compiler + build stdlib — what can be done to make this easier?

[Kobzol]

Hi, thanks for a very comprehensive issue report :) Recursive bootstrapping of compilers is indeed a very hard problem; I'm sure you can find many existing pieces of literature online that will justify that statement.

You might be in luck, because #148795 was opened yesterday, it aims to add support for passing custom rustflags during a bootstrap build.

[oli-obk]

Moderator note: I edited out your frustrated comments as they unnecessarily distracted from the main point you were trying to make and are rude enough to easily cause maintainers to not want to work with you. This is a moderation warning, meaning similar comments in the future can result in temporary or even permanent bans.

[Kobzol]

It is possible to set LDFLAGS, CFLAGS and CXXFLAGS to LLVM using llvm.ldflags (and friends) in bootstrap.toml. Cargo doesn't really work with LDFLAGS/CFLAGS/CXXFLAGS, it doesn't (directly) build C code, after all. It should be enough to simply set those environment variables when invoking Cargo (or bootstrap) though.

[mccakit]

llvm ldflags doesn't work on its own, if I don't pass env vars build fails due to mismatch.
Basically rust llvm wrapper still thinks llvm is linked to stdc++ for some reason

[Kobzol]

It would help if you could describe what you are actually trying to achieve, as I didn't understand that. You might want to examine this file to see what happens in the build script for LLVM.

[mccakit]

I saw this line in rust/src/bootstrap/src/core/builder/cargo.rs

            self.command.env(&env, cxxflags);

in

impl Cargo { line 101

so maybe just add cxxflags and ldflags as a config option then append it?
similar to rustflags where I add it like so

    jemalloc: Option<bool> = "jemalloc",
    rustflags: Option<Vec<String>> = "rustflags",

then

    let mut rustflags = Rustflags::new(target);
    if let Some(config_data) = self.config.target_config.get(&target) {
        if let Some(target_flags) = config_data.rustflags.as_ref() {
            for arg in target_flags.iter() {
                rustflags.arg(arg);
            }
        }
    }

[mccakit]

Hmm, I will create a PR if I can actually cross compile the stdlib for 2-3 platforms with env vars.

C/CXX flags are secondary I think, the thing that matters most is being able to build the compiler and multiple std libraries

[mccakit]

It would help if you could describe what you are actually trying to achieve, as I didn't understand that. You might want to examine this file to see what happens in the build script for LLVM.

I'm trying to build rustc and standard library, I want to build my rustc with my own llvm, build the wrapper with my static libc++ compiled from that llvm and don't link to gcc_s for exceptions. I want my rustc driver to depend only on glibc.

I also want to cross compile the std library for several platforms, again without linking to the gcc_s for exceptions and stdc++ for llvm wrapper.

That is really it, I do this because I can't use rust project that provide a C++ api like slint because the default binary toolchains expect me to use stdc++, gcc_s. Even in projects like GTK I'm forced to link to gcc_s because libraries like libffi.

Sorry for writing in such a rash manner, I kinda lose myself after spending too much time on fixing stuff

[mccakit]

Oh, without env vars x.py tries to use target specific CXX compiler for building std lib for arm linux.
Just another PR point I guess.

[target.x86_64-unknown-linux-gnu]
llvm-config = "/home/mccakit/dev/llvm/bin/llvm-config"
cc = "clang"
cxx = "clang++"
ar = "llvm-ar"
ranlib = "llvm-ranlib"
linker = "clang"

like this is ignored
couldn't find required command: "x86_64-w64-mingw32-gcc"

[mccakit]

I don't think x.py is written with clang /lld at mind at all, like gcc is the expected toolchain for how x.py works
There is no flags, so gcc style linker is expected. So is for llvm wrapper.

Am I wrong?