Adding non freestanding crates to list of crates xargo builds

[kent-mcleod]

cargo-sysroot had the ability to add additional crates by providing a sysroot.toml. Are there any plans for supporting this with xargo?

[japaric]

Yeah, I think we can make Xargo obey a Xargo.toml (or a .xargo/config?) to modify which crates get build into the sysroot.

non freestanding crates

Cross compiling non freestanding crates is more complicated than cross compiling freestanding crates, because the former might require a C cross compiler to build C dependencies like jemalloc and libbacktrace. And if you want to work with std you'll need to cross compile compiler-rt as well ... which is a PITA to compile.

jemalloc, libbacktrace, compiler-rt

Anything that requires these will require either hacking more logic into Xargo or "crate-ifying" them in the rust-lang/rust repo. I prefer the later.

[kent-mcleod]

So from what I have found, passing in something like
CC=arm-linux-gnueabi-gcc cargo sysroot/build ...
is usually enough to make it work, because the build_helper package does a bunch of heavy lifting to find the right compiler and linker if it is installed. So xargo could just expect the user to have a correctly setup crosscompiler environment and merely check if its present.

As for compiler-rt, you already download the source for it when building the sysroot, and building it is just (in the src/.. dir)
./configure --target=arm-unknown-linux-gnueabi && make arm-unknown-linux-gnueabi/rt/libcompiler-rt.a
where arm-unknown-linux-gnueabi can be extracted from the target.json as the llvm-target triple.

[kent-mcleod]

Anything that requires these will require either hacking more logic into Xargo or "crate-ifying" them in the rust-lang/rust repo. I prefer the later.

Actually yea, something like the alloc_jemalloc crate but for compiler-rt and others would be better. And because compiler-rt produces libcompiler-rt.a it could be wrapped with a crate that just produces a staticlib only.

[japaric]

CC=arm-linux-gnueabi-gcc cargo sysroot/build

I think that should be CC_$underscored_target=$prefix-gcc (e.g. CC_arm_unknown_linux_gnueabihf=arm-linux-gnueabihf-gcc). Setting CC might also override the host compiler.

build_helper
So xargo could just expect the user to have a correctly setup crosscompiler environment and merely check if its present.

(what's build_helper?)

the gcc crate only work correctly for some built-in targets (Xargo primary objective are custom targets) and the gcc prefixes it selects are based on what Ubuntu/Debian chose. And that breaks down when your Linux distribution installs a toolchain like armv7-unknown-linux-gnueabihf-gcc instead of the expected arm-linux-gnueabihf-gcc. So I don't want to rely on gcc auto-detection; setting the env variables is safer.

./configure --target=arm-unknown-linux-gnueabi && make arm-unknown-linux-gnueabi/rt/libcompiler-rt.a

The problem with this is that: (a) configure && make is on its way to deprecation and you should use cmake instead, but cmake requires you to have llvm-config installed which is a logistics nightmare. And (b) Neither configure && make or cmake work out of the box for custom targets like thumbv7m-none-eabi; I had to modify rust-lang/compiler-rt to make them work with those targets.

Actually yea, something like the alloc_jemalloc crate but for compiler-rt and others would be better. And because compiler-rt produces libcompiler-rt.a it could be wrapped with a crate that just produces a staticlib only.

nods

I actually have this idea of building libcompiler-rt.a using a build.rs but without using configure && make or cmake. Instead it would use Rust's cfg mechanism (target_os, etc) and direct calls to gcc and (g)as. Haven't had time to test it yet.

[kent-mcleod]

(what's build_helper?)

I was referring to rust-lang/rust: src/build_helper (I thought it had more helper methods than it actually does). It's used by the build.rs in libstd. And I thought it was doing a bunch of environment checking, but its actually done by the libbacktrace configure I think which is called just before (in libstd/build.rs).

The problem with this is that: (a) configure && make is on its way to deprecation and you should use cmake instead, but cmake requires you to have llvm-config installed which is a logistics nightmare. And (b) Neither configure && make or cmake work out of the box for custom targets like thumbv7m-none-eabi; I had to modify rust-lang/compiler-rt to make them work with those targets.

Is there anywhere that provides a libcompiler-rt.a as a download for a particular triple?

[polarathene]

the user to have a correctly setup crosscompiler environment

Any chance that could be made easier with something like Docker or a VM? I think that would be useful to get going faster, then at a later stage if beneficial the user could setup the environment locally. I've seen an example Dockerfile for a Rust project recently if that's helpful. You might want to use Alpine as the base rather than ubuntu, also came across this reddit comment that suggests getting it running on Alpine should be fine :)

Could be useful addition to cu too?

[japaric]

Any chance that could be made easier with something like Docker or a VM?

Docker would help, yes. Some could make a single massive Docker image with all the cross C toolchains one can think of. The Rust team has been thinking about something different though: Make rustup capable of (automatically) installing cross C toolchains.

You might want to use Alpine as the base rather than ubuntu

You can't run rustc on Alpine (cf. rust-lang/rust#31322), so the image would have to based on Ubuntu, Debian or some other glibc based distro.

Could be useful addition to cu too?

There's already a docker image for copper.

[polarathene]

You can't run rustc on Alpine

I must have misunderstood what I read, sorry about that.

There's already a docker image for copper.

Ah, sorry I only came across cu where I didn't see a dockerfile or reference to one elsewhere in the readme.

[japaric]

I must have misunderstood what I read, sorry about that.

To clarify, you can cross compile Rust programs to the x86_64-unknown-linux-musl target. Those binaries are (fully) statically linked and can run on any linux distribution regardless of the libc it uses. You can't do the same with rustc and get a rustc that works on Alpine because there some bug in rustc/llvm that I haven't figured out how to fix.

Ah, sorry I only came across cu where I didn't see a dockerfile or reference to one elsewhere in the readme.

Don't be sorry! The docker image wasn't really documented. I have been it using for cu's Travis CI job but that's not really visible. The docker image is mentioned in the copper website but the website just came out today 😄.

[HybridEidolon]

So, is there any way we can build liblibc/libstd into our sysroots created by Xargo today, even if it involves some bootstrapping with a Makefile or similar? In my particular case, I have a suitable compiler-rt, and the target's toolchain has pthreads and lots of posix functionality provided such that using the target_os linux should theoretically work, but I am struggling to get libc and std built together. Wondering how I can just get libstd with panic=abort (i.e. no libbacktrace).

[japaric]

So, is there any way we can build liblibc/libstd into our sysroots created by Xargo today

No, at this very moment. It should be relatively easy to make Xargo build std for built-in targets (the ones in rustc --print target-list) that are not the HOST (the host field in rustc -Vv) without changing the UI (still it would be a breaking change).

Wondering how I can just get libstd with panic=abort (i.e. no libbacktrace).

In priniciple, this Cargo.toml should just work (assuming you have the rust-src component installed)

[package]
name = "foo"
version = "0.1.0"
authors = ["Jorge Aparicio <[email protected]>"]

[dependencies]
std = { path = "/home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd" }

where /home/japaric/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu is the output of rustc --print sysroot.

But it doesn't work 😄. Right now, it errors building std as a rlib which seems like a regression because that used to work.

And if you try to compile std using panic = abort in your profile (Cargo.toml) then you'll hit a LLVM assertion because it tries to compile the panic_unwind using panic=abort but it shouldn't.

So, this scenario of explicitly listing std as a dependency should work because thats how "std aware" Cargo will work. If it doesn't that's a bug that must be filled in rust-lang/rust's issue tracker.

[HybridEidolon]

Yeah, I am getting the panic_unwind assertion unfortunately, but everything else seems to work.

[japaric]

Xargo now builds everything the std crate incluning std itself. But it still won't try to build a sysroot for built-in targets; that's covered by #77.

I don't intend to add a way to pick which crates should conform the sysroot. That will be covered by std-aware cargo. So I'm going to close this.