Feature Request: Provide ABI version information to ELF, Mach-O and PE artifacts

[gangster-puppy]

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.dylib
It 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?

[linear]

NATIVE-138

[supervacuus]

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 affect soname versioning and symbolic link chains in the install path. In contrast, on macOS, they populate the ID_DYLIB load 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 MachO and ELF (and maybe even the VERSION attribute in the Windows def) has been deferred until users raise the need, as they carry ABI meaning in some deployment contexts that doesn't always align with our versioning.

For instance, an SOVERSION bump signifies a break, but it would need to align with the major (currently 0). However, the Native SDK uses major-0 versioning ("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.