Comments (13)
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 😄.
from xargo.
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.
from xargo.
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.
from xargo.
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.
from xargo.
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.
from xargo.
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.
from xargo.
(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?
from xargo.
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?
from xargo.
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.
from xargo.
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.
from xargo.
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).
from xargo.
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.
from xargo.
Yeah, I am getting the panic_unwind
assertion unfortunately, but everything else seems to work.
from xargo.
Related Issues (20)
- xargo doesn't work with cranelift HOT 7
- Move away from travis-ci.org HOT 3
- v0.3.22 tag missing from repository HOT 1
- Cross compiling from Linux to Windows with disabled default features for std is giving error HOT 6
- Cross compile Tier3(mipsel-unknown-linux-uclibc) error HOT 4
- error[E0463]: can't find crate for `std` HOT 3
- Cargo cannot build `compiler_builtins` for `aarch64-unknown-linux-musl` HOT 6
- std hashbrow dependency error HOT 1
- Crazy unresolved import (all files are there) HOT 1
- rustup toolchain HOT 1
- Segmentation fault on aarch64 HOT 1
- Link error on aarch64 HOT 1
- "cant find crate std" error when trying to build DLL
- New issues
- windows build error HOT 1
- Problems with basic setup when using XARGO_RUST_SRC HOT 3
- target powerpc-unknown-linux-gnu - can't even build simple hello world
- v0.3.26 has a subtle breaking change HOT 1
- xargo cannot compile `riscv64gc-unknown-llinux-musl`
- contributing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xargo.