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 1743

Summary: [WIP PATCH] CMake produces libraries with wrong filename/SONAME
Product: SDL Reporter: David Gow <david>
Component: buildAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: azamat.hackimov
Version: HG 2.0Keywords: target-2.0.0
Hardware: All   
OS: Linux   
Attachments: First version of a patch to emulate libtool's "release" option in CMake.
Emulate libtool's release option in CMake (v2)

Description David Gow 2013-03-07 02:20:51 UTC
Created attachment 1060 [details]
First version of a patch to emulate libtool's "release" option in CMake.

As discussed on the list, the autotools build backend uses libtool's "release" option, giving us the SONAME libSDL2-2.0.so.0, whereas CMake doesn't, giving us libSDL2.so.0

While libSDL2.so.0 has some small advantages (being simpler and matching the names on some other OSes better), many products have already been developed expecting libSDL2-2.0.so.0, which better matches SDL 1.2's SONAME. It seems clear, therefore, that most developers prefer this name.

This patch emulates libtool's functionality, making libSDL2-2.0.so.0 the name of the shared library, while leaving libSDL2.a as the filename of the static library. Unlike with libtool, no libSDL2.so symlink is yet made. I also haven't tested this on anything but Linux, so it might break other platforms. :/

This and #1709 should be all I need to switch over to CMake for my SDL2 projects!

-- David
Comment 1 Sam Lantinga 2013-03-09 02:23:58 UTC
libtool creates libSDL2.so and libSDL2-2.0.so.0 which are symlinks to libSDL2-2.0.so.0.0.0 which has an SONAME of libSDL2-2.0.so.0

It has a relatively complex system of taking breaking and non-breaking version numbers and translating them into library number changes which I'd like to retain in the CMake support.  It's useful to be able to designate a revision which is bugfix only, vs added functionality vs breaking functionality.

Is that something that CMake supports?
Comment 2 David Gow 2013-03-09 03:22:15 UTC
The current CMake build (with this patch) creates:
- libSDL2-2.0.so (symlink->libSDL2-2.0.so.0)
- libSDL2-2.0.so.0 (symlink->libSDL2-2.0.so.2.0.0)
- libSDL2-2.0.so.2.0.0 (the actual library).

Which have the SONAME "libSDL2-2.0.so.0". (This patch only adds the "-2.0" part to the names, at the moment it's just "libSDL2.so*".

The version numbers are set in almost exactly the same way as with autotools/libtool. The variables SDL_MAJOR_VERSION, SDL_MINOR_VERSION, SDL_MICRO_VERSION, SDL_INTERFACE_AGE and SDL_BINARY_AGE are set in both configure.in and CMakeLists.txt, and the exact same versions are calculated. The only differences (at present) are the lack of a "libSDL2.so" symlink, the library having a version of "2.0.0" rather than "0.0.0" (which I've just tracked down) and there being no libtool ".la" file (which we could generate if it's really important).

I should be able to get a revised patch out soon that fixes most of those issues. The real trick is going to be making sure that it doesn't interfere with the names on windows, which shouldn't have the libtool-esque names.

-- David
Comment 3 David Gow 2013-03-09 04:47:10 UTC
Created attachment 1062 [details]
Emulate libtool's release option in CMake (v2)

New version of the patch. This is pretty much complete except for windows support.

It fixes the so.2.0.0 problem (it now matches libtool's .so.0.0.0) and creates a libSDL2.so symlink.

-- David
Comment 4 Ryan C. Gordon 2013-07-12 22:15:44 UTC
(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 2.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.
Comment 5 Sam Lantinga 2013-07-27 05:51:03 UTC
Thanks for the patch David, this is in for the 2.0 release!
http://hg.libsdl.org/SDL/rev/e5ae3502a25e