Repository navigation
Feature Request: Provide ABI version information to ELF, Mach-O and PE artifacts #1428
Description
Activity
Hi @gangster-puppy, thanks for the report.
The version of sentry-native code is 0.11.3, and the same code I compiled on Windows is ok, maybe the cmakelist.txt has something wrong?
I am not sure what you mean by "ok", but our Windows build artifacts offer version information because of an explicitly constructed resource file with the respective metadata during the build. Our Windows users expressly requested this.
There is no automatic versioning mechanism in CMake that would take, for instance, the project version into the binaries.
What CMake offers are target properties for versioning, but their outcomes differ significantly between the platforms the Native SDK supports. For instance, for
ELF, they primarily affectsonameversioning and symbolic link chains in the install path. In contrast, on macOS, they populate theID_DYLIBload command (though not the source version, which is considered independent) and also create a symbolic link chain. In addition to that, the content and associated rules of the actual version also differ in how target version properties are applied on the supported platforms.So, in short, deciding on versioning output for
MachOandELF(and maybe even theVERSIONattribute in the Windowsdef) has been deferred until users raise the need, as they carryABImeaning in some deployment contexts that doesn't always align with our versioning.For instance, an
SOVERSIONbump signifies a break, but it would need to align with the major (currently0). However, the Native SDK usesmajor-0versioning ("initial development") according to the semver spec and signifies a break with a minor bump. So there are a couple of rules that have to be specified before adding this.The Native SDK is primarily a source distribution, and as such, binary metadata (especially given the many potential outputs the Native SDK supports) has historically had a lower priority. Since the Native SDK versions consider all source changes, our breaking changes (expressed in minor bumps) are often not changes in API or ABI but rather in other aspects, such as changes in the build or behavioral changes that weren't part of the contract (but people still could be relying on). Expressing the same kind of breakage in terms of ABI variables might lead to confusion.
So, while this is certainly something that the build scripts can be extended with, no time has yet been invested in specifying the ABI versioning output for the supported platforms.
- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Oct 23, 2025 1 remaining item
- added a commit that references this issue
on Sep 17, 2026 - added 7 commits that reference this issue
on Sep 17, 2026 - added a parent issue
on Sep 21, 2026
Metadata
Metadata
Assignees
Projects
- Status
When I build on my MacBook pro with commands like below:
cmake -B build_universal -DCMAKE_BUILD_TYPE=RelWithDebInfo \ ✔ 09:47:16 -DCMAKE_OSX_ARCHITECTURES="x86_64;arm64" cmake --build build_universal --parallel cmake --install build_universal --prefix install_universal --config RelWithDebInfo lipo -info install_universal/lib/libsentry.dylibIt shows:
The version of sentry-native code is 0.11.3, and the same code I compiled on Windows is ok, maybe the cmakelist.txt has something wrong?