Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Detect musl in cmake and link with libunwind #4645

Merged

Conversation

JohanEngelen
Copy link
Member

No description provided.

@JohanEngelen
Copy link
Member Author

@kinke Is it worthwhile letting the CI for cross-compiling druntime/phobos (and ldc-build-runtime probably too?) know about LDC's folder with cmake modules..... Or should I just move the CHECK_MUSL macro inside the runtime CMakeLists.txt and be happy?

@kinke
Copy link
Member

kinke commented May 5, 2024

Sigh, if the pragma(lib, …) was supported by the GNU linkers too (not just lld), we could simply embed a reference in a central druntime object file and let the linker handle everything.

If the compiler implicitly added -lunwind as 'platform-lib' for musl targets, the druntime integration tests would require less adaptations (then only required when linking via C(++) compiler).

Wrt. detecting musl, another option might be to check the LLVM host triple (llvm-config --host-target - AFAICT, would need a new llvm_set(HOST_TARGET host-target) in FindLLVM.cmake to set LLVM_HOST_TARGET), checking for a musl environment.

Wrt. integrating that in runtime/CMakeLists.txt, a potential option might be to (ab)use our TARGET_SYSTEM variable, adding Musl to that list, similar to Android (full TARGET_SYSTEM: Android;Linux;UNIX). For autodetection as part of a full LDC build, we could use LLVM_HOST_TARGET; for cross-compiling the libs, TARGET_SYSTEM would need to be specified manually (but that's standard - just nice not having to remember to additionally set an extra MUSL_LIBC variable when cross-compiling to a musl target).

@JohanEngelen
Copy link
Member Author

If the compiler implicitly added -lunwind as 'platform-lib' for musl targets, the druntime integration tests would require less adaptations (then only required when linking via C(++) compiler).

LDC already does this, but indeed the problem is C/C++ linking.

ldc/driver/linker-gcc.cpp

Lines 684 to 686 in 40ad5f7

if (triple.isMusl() && !global.params.betterC) {
args.push_back("-lunwind"); // for druntime backtrace
}

Wrt. detecting musl, another option might be to check the LLVM host triple (llvm-config --host-target - AFAICT, would need a new llvm_set(HOST_TARGET host-target) in FindLLVM.cmake to set LLVM_HOST_TARGET), checking for a musl environment.

Wrt. integrating that in runtime/CMakeLists.txt, a potential option might be to (ab)use our TARGET_SYSTEM variable, adding Musl to that list, similar to Android (full TARGET_SYSTEM: Android;Linux;UNIX). For autodetection as part of a full LDC build, we could use LLVM_HOST_TARGET; for cross-compiling the libs, TARGET_SYSTEM would need to be specified manually (but that's standard - just nice not having to remember to additionally set an extra MUSL_LIBC variable when cross-compiling to a musl target).

I also want the autodetection to work for non-cross compile builds, just for building runtime with user-specified options (e.g. ASan stuff); then I cannot use llvm-config (although a good idea). So for now I'll stick with the current check but add it as macro to runtime/CMakeLists.txt. And I will add detection of "Musl" string in TARGET_SYSTEM, for user-override / cross-compiling capability.

@JohanEngelen JohanEngelen enabled auto-merge (squash) May 17, 2024 14:35
@JohanEngelen JohanEngelen merged commit 4c2c8ca into ldc-developers:master May 17, 2024
23 checks passed
@JohanEngelen JohanEngelen deleted the musl_druntime_test_linkunwind branch May 17, 2024 15:35
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants