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 2915

Summary: Library version number is different on Mac between configure and CMake scripts
Product: SDL Reporter: Ryan C. Gordon <icculus>
Component: buildAssignee: Ryan C. Gordon <icculus>
Status: REOPENED --- QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: josh+sdl, sezeroz
Version: HG 2.0   
Hardware: x86   
OS: Other   

Description Ryan C. Gordon 2015-03-20 16:04:24 UTC
If you run otool -L libSDL2-2.0.0.dylib on Mac OS X, with a library built with the CMake file, you get this...

        libSDL2-2.0.0.dylib (compatibility version 0.0.0, current version 0.4.0)

...same command if built with configure script...

        libSDL2-2.0.0.dylib (compatibility version 5.0.0, current version 5.0.0)


I have no idea which number is correct, neither of them actually look correct to me.  :)

If you build against one and try to run the app you built with the other library, it refuses to load:

[icculus@caridad ~/projects/SDL/test/buildbot]$ ./testaudioinfo
dyld: Library not loaded: /usr/local/lib/libSDL2-2.0.0.dylib
  Referenced from: /Users/icculus/projects/SDL/test/buildbot/./testaudioinfo
  Reason: Incompatible library version: testaudioinfo requires version 5.0.0 or later, but libSDL2-2.0.0.dylib provides version 0.0.0


Relinking the app fixes that, but it would be better to just fix the library version that CMake produces.

Maybe affects other platforms too, only tested on Mac OS X.


We probably need to set this in the CMake project?

    http://www.cmake.org/cmake/help/v3.0/prop_tgt/SOVERSION.html

I don't know, though.

--ryan.
Comment 1 Ryan C. Gordon 2015-04-07 04:57:55 UTC
(sorry if you get a lot of copies of this email, I'm marking several bugs at once)

Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.

(Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)

--ryan.
Comment 2 Sam Lantinga 2016-10-07 23:50:30 UTC
The configure script is correct. I update the framework built by Xcode to match.
Comment 3 Ozkan Sezer 2018-10-02 12:43:42 UTC
CMake is still not fixed for dylib versioning.  Building SDL2
as a dylib from today's hg using cmake, I get:
  compatibility version 0.0.0, current version 0.0.0

... which is unacceptable and broken.  Should be:
  compatibility version 1.0.0, current version 10.0.0
Comment 4 Ozkan Sezer 2018-10-02 18:51:10 UTC
I attempted to do something like this:

diff --git a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -46,6 +46,9 @@
 set(SDL_INTERFACE_AGE 0)
 set(SDL_BINARY_AGE 9)
 set(SDL_VERSION "${SDL_MAJOR_VERSION}.${SDL_MINOR_VERSION}.${SDL_MICRO_VERSION}")
+# this should match the versions in Xcode project file:
+set(DYLIB_CURRENT_VERSION "10.0.0")
+set(DYLIB_COMPATIBILITY_VERSION "1.0.0")
 
 # Set defaults preventing destination file conflicts
 set(SDL_CMAKE_DEBUG_POSTFIX "d"
@@ -1738,6 +1741,8 @@
   if(APPLE)
     set_target_properties(SDL2 PROPERTIES
       MACOSX_RPATH 1
+      VERSION ${DYLIB_CURRENT_VERSION}
+      SOVERSION ${DYLIB_COMPATIBILITY_VERSION}
       OUTPUT_NAME "SDL2-${LT_RELEASE}")
   elseif(UNIX AND NOT ANDROID)
     set_target_properties(SDL2 PROPERTIES

... which sets dylib versions correctly, but then it screws up dylib
file names by trying to use symlinks:

$ ls -l *dylib
-rwxrwxr-x. 1 ozkan ozkan 1171180 Oct  2 21:20 libSDL2-2.0.10.0.0.dylib
lrwxrwxrwx. 1 ozkan ozkan      24 Oct  2 21:20 libSDL2-2.0.1.0.0.dylib -> libSDL2-2.0.10.0.0.dylib
lrwxrwxrwx. 1 ozkan ozkan      23 Oct  2 21:20 libSDL2-2.0.dylib -> libSDL2-2.0.1.0.0.dylib
Comment 5 Ozkan Sezer 2018-10-15 18:34:18 UTC
By-passing the cmake automated interfaces and adding the linker flags
directly to EXTRA_LDFLAGS works for me, and it doesn't make a mess by
creating unwanted symlinks, of course: like patch below.  Should I go
on and apply?

diff --git a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -45,8 +45,11 @@
 set(SDL_MICRO_VERSION 9)
 set(SDL_INTERFACE_AGE 0)
 set(SDL_BINARY_AGE 9)
 set(SDL_VERSION "${SDL_MAJOR_VERSION}.${SDL_MINOR_VERSION}.${SDL_MICRO_VERSION}")
+# the following should match the versions in Xcode project file:
+set(DYLIB_CURRENT_VERSION 10.0.0)
+set(DYLIB_COMPATIBILITY_VERSION 1.0.0)
 
 # Set defaults preventing destination file conflicts
 set(SDL_CMAKE_DEBUG_POSTFIX "d"
     CACHE STRING "Name suffix for debug builds")
@@ -450,8 +453,10 @@
   endif()
 
   if(APPLE)
     list(APPEND EXTRA_LDFLAGS "-Wl,-undefined,error")
+    list(APPEND EXTRA_LDFLAGS "-Wl,-compatibility_version,${DYLIB_COMPATIBILITY_VERSION}")
+    list(APPEND EXTRA_LDFLAGS "-Wl,-current_version,${DYLIB_CURRENT_VERSION}")
   else()
     set(CMAKE_REQUIRED_FLAGS "-Wl,--no-undefined")
     check_c_compiler_flag("" HAVE_NO_UNDEFINED)
     set(CMAKE_REQUIRED_FLAGS ${ORIG_CMAKE_REQUIRED_FLAGS})
Comment 6 Ozkan Sezer 2018-10-23 09:27:55 UTC
PING?
Comment 7 Ozkan Sezer 2018-10-25 08:11:35 UTC
I applied the patch from #c5.  If there is a better way of doing this,
please revert.  Closing for now.
http://hg.libsdl.org/SDL/rev/a46837d71c0a
Comment 8 Joshua Root 2018-11-14 17:42:16 UTC
The resolution of bug 4367 means that this is once again an issue. As I mentioned in that bug, the right solution would be to increase the versions set by cmake to match autotools, and keep them in sync going forward.