release: preserve SONAME/install_name symlinks in liblbug tarballs#414
Merged
adsharma merged 1 commit intoApr 22, 2026
Merged
Conversation
The liblbug shared-library tarballs (liblbug-linux-*.tar.gz, liblbug-osx-*.tar.gz) extracted to an unversioned filename (liblbug.so, liblbug.dylib) whose embedded SONAME / install_name referred to a version-suffixed name (liblbug.so.0, @rpath/liblbug.0.dylib) that was NOT present in the archive. A consumer linking -llbug would succeed at link time but fail at load time with "Library not loaded: @rpath/liblbug.0.dylib" / "cannot open shared object file: liblbug.so.0". Root cause: the precompiled-bin packaging step used cp -L, which dereferenced the cmake-generated symlink chain liblbug.so -> liblbug.so.0 -> liblbug.so.0.15.3 down to the real file, discarding the intermediate names that satisfy SONAME / install_name. Fix (Option B from the bug report, matching Homebrew/distro convention and what `make install` into /usr/lib produces): copy and archive the full symlink chain, so the unversioned link-time name, the versioned SONAME / install_name, and the real file are all present in the tarball. Also adds a CI verification step that reads the SONAME (via readelf) / install_name (via otool -D) from the built library and asserts a tarball entry matches, so any regression is caught at build time rather than on a user's machine. The Windows shared build is unaffected (PE uses the DLL name directly, no SONAME indirection) and the static libraries are unaffected (no SONAME / install_name).
Contributor
|
Looks right. Testing it here: https://github.com/LadybugDB/ladybug/actions/runs/24799643808 It could affect other language bindings such as: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The liblbug shared-library release tarballs (
liblbug-linux-{x86_64,aarch64}.tar.gz,liblbug-osx-{x86_64,arm64}.tar.gz) have inconsistent on-disk filenames vs the SONAME / install_name embedded in the library. A consumer that does the obvious thing — untar, link-llbug, run — succeeds at link time but fails at load time withVerified on v0.15.3; the same pattern is present on v0.15.2 and v0.15.1.
Repro (macOS)
Repro (Linux)
Root cause
src/CMakeLists.txt:26-29setsVERSION/SOVERSIONon thelbug_sharedtarget, which is semantically correct — CMake emits the standard three-name chain into the install tree:The bug lives in
.github/workflows/precompiled-bin-workflow.yml: the "Collect artifacts" step usescp -L install/lib/liblbug.dylib .(and the Linux analogue), which dereferences the symlink chain down to the real file — discarding the intermediate SONAME / install_name names. The archive ends up with only the unversioned name, but the library internally still refers to the versioned one.Fix
This PR takes Option B from the bug report (matching Homebrew/distro convention and what
make installinto/usr/libproduces): copy and archive the full symlink chain, so the unversioned link-time name, the versioned SONAME / install_name, and the real file are all present in the tarball.cp -Lwithcp -Pand enumerate both the unversioned name and the versioned glob.tararguments to includeliblbug.so.*/liblbug.*.dylibso symlinks survive into the tarball (tarpreserves symlinks as symlinks by default).SONAME(readelf) /install_name(otool -D) from the built library and asserts a tarball entry with that name exists, so any future regression is caught at build time rather than on a user's machine.Scope
perfvariant ships the static library only (unaffected).lbugCLI links the static library, not the shared one (unaffected).After the fix, tarballs contain
macOS (
liblbug-osx-<arch>.tar.gz):Linux (
liblbug-linux-<arch>.tar.gz):The new CI verification step reproduces the bug report's one-liner check and fails the workflow if the tarball doesn't contain an entry matching the library's advertised name.
Test plan
Build Precompiled Binariesworkflow passes on this PR (Linux compat x86_64, Linux compat aarch64, macOS x86_64, macOS arm64).Verify tarball SONAME consistency (Linux compat)steps succeed and print the SONAME + tarball listing.Verify tarball install_name consistency (macOS)steps succeed and print the install_name + tarball listing.