We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4367

Summary: compatibility version decreased between 2.0.8 and 2.0.9
Product: SDL Reporter: Joshua Root <josh+sdl>
Component: buildAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: major    
Priority: P2 CC: contact, sezeroz
Version: 2.0.9   
Hardware: All   
OS: Mac OS X (All)   

Description Joshua Root 2018-11-08 06:05:04 UTC 
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
Comment 1 Ozkan Sezer 2018-11-08 08:03:15 UTC 
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.
Comment 2 Joshua Root 2018-11-08 08:32:07 UTC 
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.
Comment 3 Ozkan Sezer 2018-11-08 09:16:49 UTC 
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.
Comment 4 Joshua Root 2018-11-08 09:38:15 UTC 
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.
Comment 5 Joshua Root 2018-11-10 07:35:53 UTC 
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
Comment 6 Sam Lantinga 2018-11-13 00:35:32 UTC 
That change was backed out, thanks!
https://hg.libsdl.org/SDL/rev/d274fa9731b1
Comment 7 Ozkan Sezer 2018-11-14 17:25:44 UTC 
*** Bug 4385 has been marked as a duplicate of this bug. ***