Stop linking libc++ into the Java extension on Linux - #108
Conversation
libJavaExtension.so.1.0 shipped with these runtime dependencies:
libc++.so.1 libc++abi.so.1 libunwind.so.1 libstdc++.so.6 libc.so.6
The target is compiled with GCC and therefore already links GNU libstdc++, so
the explicit libc++ / libc++abi linkage put two C++ runtimes in one .so and
dragged in libunwind through libc++abi. None of those three are libraries the
SQL container images are required to ship.
RHEL images carry none of them, so the Java extension never loaded there:
Exthost: Load extension failed libunwind.so.1: cannot open shared object file
That produced 15 'Java' script errors plus 7 cascading KeyNotFoundException on
both RHEL 9 and RHEL 10 - 22 failures, identical on each. Ubuntu passed only
because its images happen to carry libc++, libc++abi and libunwind.
Python and R link libstdc++ alone; Java now matches them. Same defect class as
the dynamic Boost dependency fixed in #107: a find_library resolving something
the runtime images do not provide, invisible to a green build.
Linux-only - the change sits inside if(PLATFORM STREQUAL linux) and the Windows
branch is untouched. No source files change.
There was a problem hiding this comment.
Pull request overview
This PR fixes Linux runtime loading failures for the Java language extension by removing an unintended dependency on LLVM’s C++ runtime stack (libc++/libc++abi, and transitively libunwind) from libJavaExtension.so, aligning Java’s shipped dependencies with the existing Python and R extensions.
Changes:
- Remove explicit linking of
libc++andlibc++abiin the Linux CMake branch forJavaExtension. - Keep only the necessary
dllinkage on Linux. - Add an in-file comment explaining the rationale and observed failure mode on RHEL containers.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Update on the Ubuntu 24.04 item. The PVS causality re-run never executed. It was queued at 06:51 and is still reported That is a CloudTest scheduler backlog, not a signal about this change. A stalled run is not a result, so I am not going to present it as one. The classification does not depend on that verdict. Two independent lines of evidence, both already in hand: 1. The R binary is functionally unchanged by this PR. 2. Same payload, same drop, four arms:
Appearing on one arm and absent on three, with identical bits, is the definition of flaky rather than caused. The failure is If the re-run is ever released by the scheduler I will post the verdict here. If it contradicts the binary evidence above, I would treat the attribution as suspect rather than the diagnosis - but I will report it either way. Nothing about this changes the RHEL result: RHEL 9 and RHEL 10 both went 22 failures to 0, with Java, Python and R all passing. |
|
Causality verdict, as promised. The re-run was eventually released by the scheduler and the board closed. The R test fails 3/3 on the baseline and 1/3 with this change. It is not merely unrelated to this PR - it reproduces more reliably without it. That settles the question raised earlier, and it agrees with the binary evidence: The second entry, Final position across all four Linux arms on drop
No test regressed. Both RHEL distros went from 22 failures to zero, with Java, Python and R all passing. |
Aniruddh Munde (Aniruddh25)
left a comment
Aniruddh Munde (Aniruddh25)
left a comment
There was a problem hiding this comment.
Thanks for fixing so many tests!
Summary
libJavaExtension.soshipped with a runtime dependency on LLVM's C++ stack, which the SQL container images are not required to provide. RHEL images ship none of it, so the Java language extension never loaded on RHEL at all.Cause
language-extensions/java/src/CMakeLists.txtlinkedlibc++andlibc++abiexplicitly. The target is compiled with GCC, so it already links GNUlibstdc++- the result was two C++ runtimes in one.so, withlibunwindarriving transitively throughlibc++abi:Ubuntu passed only by accident, because its images happen to carry those three libraries. Python and R have always linked
libstdc++alone.Change
Two lines removed, one changed, inside
if (${PLATFORM} STREQUAL linux). No source files change; the Windows branch is untouched.libJavaExtension.sonow reports:Failure breakdown
All 22 failures on each RHEL distro trace to this one cause:
'Java' script error-InstallLanguageTests :: Setup,ThirdParty.Java.LibraryManagementFunctional :: SetupKeyNotFoundException- matchingCleanupsExecuted test counts rose ~600-750 per distro, because
InstallLanguageTests :: Setupno longer aborts everything behind it.Validation
Package
1.0.0-CI-java-libcxx-validate-20260811.1, drop18.0.256-2-1780. Boards held shelveset, test filter and quality gate constant, varying only the distro image. Counts are actualFailedoutcomes -totalTests - passedTestsreads 76 because it also absorbsNotExecuted.Windows was not board-validated and does not need to be: the change is confined to the
linuxbranch of one CMakeLists and alters no source file, so there is no mechanism by which Windows compilation or behaviour changes. The Windows PR pipeline provides the compile proof.