Skip to content
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

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.

runtime/CMakeLists.txt Outdated Show resolved Hide resolved
@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants