Change:
panic_abort = { path = "../panic_abort" } core = { path = "../core" } libc = { version = "0.2.74", default-features = false, features = ['rustc-dep-of-std'] } <del> compiler_builtins = { version = "0.1.32" } </del> <ins> compiler_builtins = { version = "0.1.35" } </ins> profiler_builtins = { path = "../profiler_builtins", optional = true } unwind = { path = "../unwind" } hashbrown = { version = "0.8.1", default-features = false, features = ['rustc-dep-of-std'] }

Discussion:
When building a statically-linked Rust binary crate for the target, linking a crate fails with the following error: Expected result: the crate successfully compiles. Actual result: the crate fails to compile, with an error during the linking stage. Platform: Ubuntu 18.04, x8664. Output of : MUSL standard C library version: 1.1.20. C compiler: MIPS GCC version 7.3, provided by Ubuntu 18.04 (). I tried searching the open and closed issues for this project, and couldn't find any others exhibiting this same error. Forgive me if this is the wrong place to file this bug, but I'm not entirely sure how to debug this problem, so I'm starting here with Rust. The file in makes a call to on big-endian hosts (). This function gets translated into the symbol for the MIPS target, and should be present in the compiler's built-in library, but it appears it's absent here. Now, I can see that uses GCC 5.3 from the OpenWRT toolchain. I'm not entirely sure why this should give any different results from using the GCC 7.3 package provided by Ubuntu 18.04 (, which provides GCC 5.5, and the results are the same (fails to link due to undefined reference to ). Here is the full error message from trying to build the crate: An easy way to reproduce this is to create a with the following contents, and then build it with :
The necessary functions should be to the .
This does look like an interesting idea, but when trying to compile with that crate, I get lots of errors of this sort: You should be able to recreate this by adding the following line to the I mentioned in the original issue, just before the line at the end: I'm currently working on a project that I'd like to keep on the stable channel. Will this crate not work at all on the stable channel?
modify labels: +O-musl
possibly related to
Any updates with this issue? Have the same problem
Adding "-C", "link-args=-lgcc" to re-add libgcc removed by -nostdlib to rustargs fixes the problem, at least for the simple hello world. Or you could implement __bswapsi2 yourself.

I'm guessing that openwrt toolchain targets mips32 as opposed of mips32r2, so it requires "libcall" for bswap. Hope it helps.
It works, thanks!

Cross compiling fails with the linker being unable to find , and code: I'm compiling the default hello-world application, and it works fine for in addition to working fine for . I installed musl the same way for both aarch64 and for armhf, so I'm not sure what the issue would be. Furthermore, I can compile a simple hello-world application written in C with the musl standard library just fine. Note: I have encountered this issue both in Arch Linux with the 4.14.4 kernel and Ubuntu 16.04 with the 4.4.0 kernel. version info for the output below, although this happens with nightly and stable: output:
Yeah this is a known issue which needs to be fixed in the compiler_builtins crate. See
I guess my followup is why is an allowed target in Rust if doesn't exist in the language and linking anything doesn't work.
Good question, it's not entirely clear to me if it's actually compiler_builtins responsibility to provide these. For now you should be fine if you also link libgcc.
Is there any workaround? Say, some combination of #[cfg(link...)] and
It would be greatly appreciated if anyone could provide any ideas for any kind of temporary workaround for this until it is properly fixed. I don't care if certain functionality (such as 128-bit integers or whatever) doesn't work. Being able to build static musl executables for aarch64 would be very useful to me.
Does linking libgcc not work?
There are some use-cases for 64-bit statically linking with musl: for example, sports a 64-bit Linux kernel and 32-bit only apps/libs (no 64-bit ld-linux*.so installed). A 64-bit statically linked executable would work out of the box.
In case anyone is blocked on this, here's a workaround:
This should be reopened due to
just mentioned this as only-working-with-workaround (). Reopening as requested by because of reverted fix PR
I was anyway able to cross-compile to aarch64 musl target using this .cargo/config (thanks for the workaround!):
solution worked for me on Windows I still had to for the moment, not sure how to get to ask for the right one.
So, what exactly is needed to fix this without the ?

is quadruple precision add, is quadruple precision multiplication and is quadruple precision substruction. the symbol is equal to this C function: from gcc and from llvm compiler-rt provide the implement of , and . In rust we use compiler-builtins (writing in rust) to replace llvm compiler-rt (writing in c and llvm asm) quadruple precision, and in C, means 128bit float number, but rust don't have type, so those A temporary fix is linking to or , but permanent fix won't exist until rust have
The crate now has an implementation for AArch64 long double intrinsics, so this issue is solved in most cases. However, because coming from , using in combination with may not enable the , causing this issue to users of and in the latest Rust builds. Therefore, users of may still need to work around this issue by either: Linking with the GCC intrinsics implementation (), as mentioned above. Explicitly build with the feature, by setting and setting up the environment variable to the path to the source, similarly to : The second option is more complex to set up, but it should produce outputs closer to the usual pre-built Rust binaries.