This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.9
Reported for operating system, platform: Mac OS X (All), All

Comments on the original bug report:

On 2018-11-08 06:05:04 +0000, Joshua Root wrote:

The change resulting from Bug 4208 changed the compatibility_version of libSDL2 from 9.0.0 to 1.0.0. This is simply wrong.

This means that programs linked against 2.0.9 are considered by the dynamic linker to be compatible with all previous versions of libSDL2. This is not the case since new public symbols have been added.

The way compatibility_version and current_version are meant to work is:

• current_version increases every time the library changes in any way.
• compatibility_version is increased to match current_version whenever new public symbols are added.

Thus both versions should only ever increase. The solution to the Xcode project and autotools not having matching versions should have been to increase the version(s) in the Xcode project.

Reference: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html

On 2018-11-08 08:03:15 +0000, Ozkan Sezer wrote:

Three different build systems had three different versioning (and
cmake was the worst of them.) Official libsdl.org-distributed osx
binaries are Xcode-generated, we took that as the base, adjusted
the rest after it: otherwise, binaries linked against autofoo and
libtool would fail running agaisnt Xcode-generated SDL frameworks.
This is the reason for that commit, bug 4208 and bug 2915. Sam &
Ryan should decide if/how to change the versioning.

On 2018-11-08 08:32:07 +0000, Joshua Root wrote:

Bug 2915 was definitely a real problem, but the version used by cmake should also have been increased to match autotools. The versions cannot decrease, or the runtime compatibility checking simply doesn't work right. The only correct solution is to increase all the versions to something >= the largest version that had been used anywhere.

On 2018-11-08 09:16:49 +0000, Ozkan Sezer wrote:

So you are saying that the Xcode project file had it wrong from
the start, which I don't agree. SDL2-2.0.0.dmg from libsdl.org
has compatibility version 1.0.0 / current version 1.0.0, and if
I link against it I can run with any newer SDL2 version that is
generated by Xcode, and as of the changes referenced here then
any SDL2 version: increasing the compatibility version without
removing apis or breaking api/abi compatibility seems wrong to
me. But Sam & Ryan should decide.

On 2018-11-08 09:38:15 +0000, Joshua Root wrote:

You have the wrong idea about what the compatibility version means. You increase it when you add public symbols, not when you break compatibility by removing them or changing their semantics. If you do that, you need to change the major version, which is part of the install_name.

I'm not saying the Xcode project had it wrong as such, just that given the existence of multiple version numbers in the wild, you need to go with the largest of them.

On 2018-11-10 07:35:53 +0000, Joshua Root wrote:

Note also that anything that was linked with an autotools-built 2.0.8 or earlier now has the exact same issue as in bug 2915 when run with 2.0.9. Example:

dyld: Library not loaded: /opt/local/lib/libSDL2-2.0.0.dylib
Referenced from: /opt/local/bin/ffmpeg
Reason: Incompatible library version: ffmpeg requires version 9.0.0 or later, but libSDL2-2.0.0.dylib provides version 1.0.0
Abort trap: 6

On 2018-11-13 00:35:32 +0000, Sam Lantinga wrote:

That change was backed out, thanks!
https://hg.libsdl.org/SDL/rev/d274fa9731b1

On 2018-11-14 17:25:44 +0000, Ozkan Sezer wrote:

*** Bug 4385 has been marked as a duplicate of this bug. ***