Repository navigation
cmake: link CMAKE_DL_LIBS into the static findopensslfeatures probe - #2473
Conversation
When cross-compiling (CMAKE_CROSSCOMPILING_EMULATOR set) the OpenSSL feature probe is linked with -static. A static OpenSSL 1.1.1 libcrypto.a pulls in dso_dlfcn.o, which references dlopen/dlsym/dlclose/dlerror, and CMake's FindOpenSSL only appends CMAKE_DL_LIBS to OpenSSL::Crypto when pkg-config lists it in Libs.private, which a bare cross sysroot does not have. The link then fails with: ld.lld: error: undefined symbol: dlopen >>> referenced by dso_dlfcn.c >>> dso_dlfcn.o:(dlfcn_load) in archive .../libcrypto.a Link CMAKE_DL_LIBS explicitly in that branch, as a library rather than a link option so it is ordered after libcrypto.a for linkers that resolve archives in a single pass. Seen with the Android NDK r29, whose libdl.a defines the four symbols; on platforms where CMAKE_DL_LIBS is empty this is a no-op.
The ordering claim only holds for linkers that resolve archives in a single pass; the NDK's lld picks libdl.a up either way. Reference rnpgp/rnp#2473 so the sed can be dropped once it lands.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2473 +/- ##
=======================================
Coverage 85.40% 85.40%
=======================================
Files 126 126
Lines 22966 22966
=======================================
Hits 19614 19614
Misses 3352 3352 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
ronaldtse
left a comment
There was a problem hiding this comment.
Thank you @jolavillette — this is a clean, well-scoped fix for a real gap in the #2396 cross-compile support. The explanation is spot-on: -static pulls in dso_dlfcn.o, bare sysroots lack pkg-config Libs.private, and CMAKE_DL_LIBS never gets added. Linking it explicitly in the same branch that adds -static is exactly right, and the library-vs-flag ordering ensures single-pass linkers resolve it after the archive. Confirmed this matches the failure mode we saw on the OHOS side. Approving.
|
@ni4 this needs your approval (1 of 2): #2473 One-line fix by @jolavillette for a real cross-compile gap from #2396: the |
Adds aarch64-linux-android cross-compile smoke tests for both the Botan and OpenSSL backends, mirroring the OHOS workflow (#2438) but with key additions: - Tests the OpenSSL backend, which the OHOS workflow does not cover; this is where the CMAKE_DL_LIBS linkage gap (#2473) manifested - Sets CMAKE_CROSSCOMPILING_EMULATOR=qemu-aarch64-static so the findopensslfeatures probe actually runs under emulation, catching the '-static' + dlopen linkage class of bugs - Post-nlohmann (#2439): no json-c dependency to cross-build - No SDK geo-restriction (unlike OHOS): the NDK downloads freely The NDK toolchain file, qemu-user-static, and cacheable dependency builds keep the workflow simple. Each backend is a separate matrix leg so a failure in one doesn't mask the other.
Follow-up to #2396 (cross-compilation with the OpenSSL backend).
When
CMAKE_CROSSCOMPILING_EMULATORis set thefindopensslfeaturesprobe is linked with-static. A static OpenSSL 1.1.1libcrypto.apulls indso_dlfcn.o, which referencesdlopen/dlsym/dlclose/dlerror, and CMake'sFindOpenSSLonly appendsCMAKE_DL_LIBStoOpenSSL::Cryptowhen pkg-config lists it inLibs.private— which a bare cross sysroot does not have. The probe then fails to link:This links
${CMAKE_DL_LIBS}explicitly in the sameCMAKE_CROSSCOMPILING_EMULATORbranch that adds-static. It is added as a library rather than a link option so it is ordered afterlibcrypto.afor linkers that resolve archives in a single pass; whereCMAKE_DL_LIBSis empty it is a no-op (target_link_libraries(t PRIVATE )is valid).Tested
Android NDK r29 (
aarch64-linux-android24-clang,ld.lld), OpenSSL 1.1.1n static,CRYPTO_BACKEND=openssl,CMAKE_CROSSCOMPILING_EMULATOR=/usr/bin/qemu-aarch64, host CMake 3.28.3 — the RetroShare Android toolchain (RetroShare/libretroshare#376):main(ee97ed7): the fourundefined symbol: dl*errors above,Error building findopensslfeatures.librnp.abuilds and installs.Native (non-cross) builds do not enter the branch and are unchanged.