Hello, is there any up-to-date documentation about current state of affairs when it comes to using a custom compiler built by crosstool-ng?
Generally I would like to use by ArchLinux system to build executables that are possible to be run on an old CentOS 7 system. This means that I need those executables to use old glibc 2.17. I've compiled the C and C++ compilers using crosstool-ng, and I am able to produce working executables that run on CentOS 7 by using the C++ compiler. But what would be the best way of convincing Cargo/Rust to use my custom gcc compiler?
(All involved systems that I care about are limited to Linux and x86_64)
It would be for you would take source for Cargo and Rust and write the code which would make that possible, I guess. Not impossible, but prepare to spend many man-years of work. Most likely by the time you would finish the original task would be long forgotten history.
More realistic approach would be to to take source of Rust compiler and adopt it to cross-compile for CentOS 7.
Also quite a challenge, of course, but people have managed to run cross-compile Rust for various strange targets from Commodore64 to Windows 95 thus changing it for CentOS 7 shouldn't be impossible.
Maybe someone already did that feat, in that case you would just only need to find such persion.
It would be very strange to expect documentation for what is not yet working. When you would write the appropriate code you would add some documentation, I guess.
If you want to build Rust programs that statically link a libc library, you can use the x86_64-unknown-linux-musl build target.
Alternatively you can use the cross toolchain with an old Docker image to build a dynamically linked Rust binary. The blog post below may be helpful (you can try using cross with the x86_64-unknown-linux-gnu:centos build environment, which has glibc 2.17).
Or are you trying to call C code via FFI from Rust?
If your build also involves other C libraries, you may need additional configuration like:
It might be easier to use an actual centos:7 container for the build though, so you match your target exactly. You can use docker/podman for that, or higher level https://containertoolbx.org/ for easier sharing with your home environment.
Currently I'm researching a way to do it without using Docker, because CentOS is a deprecated distribution, and there may be the case that Docker containers will be gone soon (they are marked as deprecated). If I won't find other solution, then I'll use Docker anyway.
Completely static executables are interesting and I'll definitely research that. If it will be just a matter of using the -musl target, then that would fix my issue.
What I did currently was that I've overriden the linker property inside the .cargo/config.toml of my "hello world" testing project and I've inserted the path to the linker driver of my crosstool-generated gcc:
and it kind of generates an executable that doesn't have any requirements on newer glibc. I'm wondering however how e.g. openssl with the vendored feature flag will behave, if I understand correctly those will still use my native system compiler and my override of linker won't work?
Also I definitely don't want to spend multiple man-years on this
That is built using the toolchain configuration from the cc crate. It will look for the CC environment variable, or if you need a target-specific compiler CC_x86_64-unknown-linux-gnu.
