C/C++ code linked to Rust code can't use some clang builtins #109717
Labels
A-FFI
Area: Foreign function interface (FFI)
A-linkage
Area: linking into static, shared libraries and binaries
C-bug
Category: This is a bug.
E-hard
Call for participation: Hard difficulty. Experience needed to fix: A lot.
E-mentor
Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
O-android
Operating system: Android
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
This is theoretically a problem that applies to all platforms, but in practice, at least on Linux, the rust compiler is saved by the forced linkage of libgcc_s (which, incidentally, is not really desirable when using clang's
--rtlib
argument, but that's another story). It is a problem on x86_64 Android.Here are steps to reproduce the problem:
Download and unpack Android NDK r25c:
Create a test crate:
Compile the crate (with some manual work that presumable cargo-apk would do):
This fails to link with, eventually:
The
__extenddftft2
symbol comes from the compilation of the functionfoo
, for the extension of the 64-bits double to a 128-bits double. It is part of libclang_rt that comes with clang. But because rustc calls the linker (clang) with-nodefaultlibs
, the clang runtime is not compiled in. And because the equivalent compiler-builtins from rustc doesn't contain all the clang builtins, this fails to link.When linking dynamic libraries, the link actually goes through without an error, but yields an error when the library is loaded at runtime because of the missing
__extenddftft2
symbol. You'll find multiple people running into this problem over the years, but somehow I didn't find it reported against the rust compiler (example: mozilla/application-services#5436).Because the
__extenddftft2
symbol exists in rustc's compiler-builtins for aarch64 android, it's not a problem on that platform.The text was updated successfully, but these errors were encountered: