-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cross compilation errors for x86_64-unknown-linux-musl from v1.72 #116348
Comments
We have a few open issues related to dynamic linking when compiling with musl, I feel also this one could also be related. @deepu105 can you try what is suggested in this comment? Does it help? |
You are cross-compiling to a musl target, from a gnu distro. The usual reason to use one of the existing How do you expect the executables you are producing to be linked? |
@saethlin I'm quite new to the MUSL world. I saw many popular Rust tools building for MUSL this way so I followed the same and afaik, the built binaries were working fine until this release in the linux distros I tried (Arch, ubuntu, Fedora). I assumed that is the purpose of cross compiling, if not what is the right way to build MUSL binaries? |
If you are depending on dynamic libraries, they need to be installed on the host system for the correct libc. In your case you depend on the dynamic libraries for X11, so you need the musl versions of those, which I don't think non-musl based distros ship. You need them both at compile time and runtime. Your user almost certainly doesn't have the musl version of these libraries installed. There are two reasons to use musl:
The second reason is almost certainly not the case for you as you want to run on Arch, Ubuntu and Fedora which are all glibc based. As for the first reason, this only works if you are fully statically linked. If you have a GUI application, unless you use a GUI toolkit which doesn't use the GPU (which rules out both GTK and QT), you pretty much can't statically link. You need to dynamically link to the GPU driver, which on a glibc based distro is compiled for glibc and thus can't be loaded by a musl based program. |
@deepu105 , While a permanent solution is being sought: Consider sticking with Rust 1.71 for this specific project if feasible. |
@Adesoji1 I'll stick to 1.71 for now. Thank you |
I don't know how to exercise the xcb functionality in here, but I'd be rather surprised if it works in these musl builds. As far as I can tell you are building Frankenstein binaries: #82912 There is no way to build portable binaries without statically linking the whole thing together. If running
then your binary is not portable across Linuxes. |
@saethlin @bjorn3 I'm definitely a newbie when it comes to static linking or MUSL. I was using the musl builds for brew formul and just did ldd on the binaries and they are indeed not statistically linked as they seem to refer to system libs. Does that mean using cargo to cross compile to MUSL actually doesn't provide a static linked binary? Then what is the purpose of cross compilation? Also is it correct to assume that even if I build for MUSL from a native MUSL distro like Alpine, the produced binary won't work for XCB? |
If you build on a musl based distro the executable will work just fine on musl based distros provided that you tell rustc to dynamically link libc. The executable won't work on glibc base distros then though. You can't statically link libxcb so dynamically linking everything is the only option. Dynamically linking to musl libc requires musl libc at runtime. You can only produce executables portable to glibc based distros using musl if you are statically linking everything, which in your case is not possible due to your dependency on the XCB dynamic library. I strongly recommend just using the glibc target and if you want compatibility with distros using an older glibc versiln, compiling on the distro with the oldest glibc version you want to support. The executable will run fine on systems using a newer glibc version than used when compiling. Just not on older glibc versions. |
This is most likely due to #111698: previously rustc would link to dynamic libraries while trying to build a static binary, which led to all sorts of problems, including crashes. Now we properly only link to static libraries when building a static binary, which is the default for the musl target. To build a dynamic binary which can link to dynamic libraries, you need to use |
Code
The cargo build for
x86_64-unknown-linux-musl
target started failing with the below errors from Rust version1.72
onwards (see backtrace for full error). The same codebase compiles without issues on1.71
. Issue seems to be around using thexcb
library and all required libs are installed on the hostapt-get install -y -qq pkg-config libssl-dev libxcb1-dev libxcb-render0-dev libxcb-shape0-dev libxcb-xfixes0-dev xauth musl-tools cargo build --release --target x86_64-unknown-linux-musl # also tried cargo rustc --release --target x86_64-unknown-linux-musl -- -lXau
Project codebase: https://github.com/kdash-rs/kdash. To reproduce, run this docker file on the cloned repo.
I have tried to build this natively on alpine Linux and cross-compilation on arch Linux and fails in both.
Version it worked on
It most recently worked on: 1.71
Version with regression
1.72 stable
1.75 nightly
Backtrace
Backtrace
The text was updated successfully, but these errors were encountered: