Set DYLIB_COMPAT_VERSION to match SDL-1.2 autotools

[jmroot]

The compatibility_version is meant to go up when new symbols are added to a library, so an executable built against an older version of a library can run against a newer version of that library, but not the other way round. The most binary compatible approach is therefore to use the highest of the different compatibility_version numbers that could have been used by SDL-1.2.

[sezero]

I don't like this: the official mac builds were made with Xcode project files and had 1.0 as the DYLIB_COMPAT_VERSION. The Autotools builds are victim of some libtool crapola.

The previous discussion: https://bugzilla.libsdl.org/show_bug.cgi?id=4208

[jmroot]

The only way this can cause problems is if you build against sdl12-compat and then try to run with an Xcode build of SDL-1.2, which I don't get the impression is at all an intended configuration. I don't know why you would want to be compatible with only the official framework builds when you can be compatible with autotools builds as well.

We have to use this patch in MacPorts regardless of whether it's accepted here, because all our existing binaries were built against our SDL 1.2 which is built with autotools.

[sezero]

The cmake file was specifically made it a configurable option, i.e. one can use -DDYLIB_COMPAT_VERSION=12.0 or something on the cmake command line, so I'm against this change. @icculus and @slouken to decide.

[jmroot]

Help me to understand your opposition. What problem do you foresee this change causing?

[sezero]

Build some program against official SDL-1.2 with compat version set to 1.0, you can't run it against a one compat version set to 12.0.

[jmroot]

Fortunately that's not the case. There's only a runtime error from dyld if the runtime compatibility_version is less than the build time one.

[jmroot]

Here's a script you can use to convince yourself of the behaviour: https://gist.github.com/jmroot/4bf947e3d0280f7d5b3ec934bdcb68e5

Note that Apple has actually disabled the runtime check altogether on recent macOS versions, for reasons unknown to me. But on older versions the test script will do this:

% ./compatver.sh 
Built against lib 1.0.0; running with lib 1.0.0
working
Built against lib 1.0.0; running with lib 2.0.0
working
Built against lib 2.0.0; running with lib 2.0.0
working
Built against lib 2.0.0; running with lib 1.0.0
dyld: Library not loaded: @executable_path/lib.1.dylib
  Referenced from: /private/tmp/libtest/./testprog
  Reason: Incompatible library version: testprog requires version 2.0.0 or later, but lib.1.dylib provides version 1.0.0
./compatver.sh: line 46: 57617 Trace/BPT trap          ./testprog

[sezero]

I see.

As I said, you always have the option of specifying DYLIB_COMPAT_VERSION on the cmake command line, so I still would like to keep the default XCode behavior default.

@icculus and @slouken to decide.

[slouken]

I misunderstood the way DYLIB_COMPAT_VERSION was used as well. We should accept this change.

[sezero]

AFAIK, all Mac systems frameworks have 1.0 as their compat version, therefore what SDL has been doing in XCode seems correct to me.

[slouken]

AFAIK, all Mac systems frameworks have 1.0 as their compat version, therefore what SDL has been doing in XCode seems correct to me.

That's what I thought as well, and I'm guessing this is a common misunderstanding, which is why that version is ignored in the latest versions of the OS. But looking at the code, it behaves the way @jmroot is describing.

I'll update SDL and the SDL satellite libraries to match.

[jmroot]

AFAIK, all Mac systems frameworks have 1.0 as their compat version, therefore what SDL has been doing in XCode seems correct to me.

Apple is able to keep their framework compat versions constant by making all newly-added exported symbols weak, and marking them up with the appropriate availability metadata. It's possible to do this with third party libs too, as long as all clients make sure to check that the symbols are available before using them at runtime.