[PATCHES] Dynamic library name: should it be libSDL2-2.0.so or libSDL2.so?

CMake and autotools are generating shared libraries with different names
(and -sonames), which is causing some compatibility problems.

The autotools backend is using libtool’s -release option, causing the
library to be named “libSDL2-2.0.so”, whereas the CMake backend, which
doesn’t use libtool at all, calls the library “libSDL2.so”. Neither use
the release number in the static library, and libtool does create a
symlink, but binary compatibility is broken, which is a little bit annoying.

Which name do you guys prefer? Personally, I think the release number is
a mite redundant, particularly if we can fix the .so version (it’s
always 0.0.0 in the autotools build, though works okay in CMake).

I’ve thrown together a patch to remove the release number from autotools
builds. Most of the patch is just changes caused by running a different
version of autoconf, so I’ve also attached a version which hasn’t had
autoconf re-run so you can see what the actual changes were more easily.
I’ve got a half-finished patch to make CMake use the release number, but
it breaks the static library at the moment, and may require some
refactoring of the CMakeLists file.

Cheers,
– David
-------------- next part --------------
A non-text attachment was scrubbed…
Name: remove-libtool-release.patch
Type: text/x-patch
Size: 42148 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130225/fe36b4ce/attachment-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed…
Name: remove-libtool-release-noautoconf.patch
Type: text/x-patch
Size: 1425 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130225/fe36b4ce/attachment-0003.bin

I always linked against libSDL2 and that’s for the dynamic library I
think. I’m using make (on Ubuntu), not cmake.

2013/2/25, David Gow :> CMake and autotools are generating shared libraries with different names

(and -sonames), which is causing some compatibility problems.

The autotools backend is using libtool’s -release option, causing the
library to be named “libSDL2-2.0.so”, whereas the CMake backend, which
doesn’t use libtool at all, calls the library “libSDL2.so”. Neither use
the release number in the static library, and libtool does create a
symlink, but binary compatibility is broken, which is a little bit
annoying.

Which name do you guys prefer? Personally, I think the release number is
a mite redundant, particularly if we can fix the .so version (it’s
always 0.0.0 in the autotools build, though works okay in CMake).

I’ve thrown together a patch to remove the release number from autotools
builds. Most of the patch is just changes caused by running a different
version of autoconf, so I’ve also attached a version which hasn’t had
autoconf re-run so you can see what the actual changes were more easily.
I’ve got a half-finished patch to make CMake use the release number, but
it breaks the static library at the moment, and may require some
refactoring of the CMakeLists file.

Cheers,
– David

You should continue to link to libSDL2, of course, but it is sometimes
helpful to have descriptive symlinks instead of hiding the major and minor
versions of a shared object. Static libraries are different, as you’re
directly linking to that version and that fact can’t change until you run
the linker again. So, it sounds to me like the libtool version is the only
one really doing it right.

Jonny DOn Thu, Feb 28, 2013 at 12:10 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

I always linked against libSDL2 and that’s for the dynamic library I
think. I’m using make (on Ubuntu), not cmake.

2013/2/25, David Gow :

CMake and autotools are generating shared libraries with different names
(and -sonames), which is causing some compatibility problems.

The autotools backend is using libtool’s -release option, causing the
library to be named “libSDL2-2.0.so”, whereas the CMake backend, which
doesn’t use libtool at all, calls the library “libSDL2.so”. Neither use
the release number in the static library, and libtool does create a
symlink, but binary compatibility is broken, which is a little bit
annoying.

Which name do you guys prefer? Personally, I think the release number is
a mite redundant, particularly if we can fix the .so version (it’s
always 0.0.0 in the autotools build, though works okay in CMake).

I’ve thrown together a patch to remove the release number from autotools
builds. Most of the patch is just changes caused by running a different
version of autoconf, so I’ve also attached a version which hasn’t had
autoconf re-run so you can see what the actual changes were more easily.
I’ve got a half-finished patch to make CMake use the release number, but
it breaks the static library at the moment, and may require some
refactoring of the CMakeLists file.

Cheers,
– David


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

When in doubt, assume libtool is wrong.

-ShawnOn 2013-02-25 00:59, David Gow wrote:

CMake and autotools are generating shared libraries with different
names (and -sonames), which is causing some compatibility problems.

The autotools backend is using libtool’s -release option, causing the
library to be named “libSDL2-2.0.so”, whereas the CMake backend, which
doesn’t use libtool at all, calls the library “libSDL2.so”. Neither
use the release number in the static library, and libtool does create
a symlink, but binary compatibility is broken, which is a little bit
annoying.

Which name do you guys prefer? Personally, I think the release number
is a mite redundant, particularly if we can fix the .so version (it’s
always 0.0.0 in the autotools build, though works okay in CMake).

When in doubt, assume libtool is wrong.

The library SONAME and filename should be “libSDL2-2.0.so.0” … there
are games in the field expecting this.

–ryan.

Wasn’t the binary compatability been broken multiple times recenty?

An unresolved symbol isn’t any better than an .so not found.On Sun, Mar 3, 2013 at 2:50 AM, Ryan C. Gordon wrote:

The library SONAME and filename should be “libSDL2-2.0.so.0” … there are
games in the field expecting this.

./lxnt

The library SONAME and filename should be “libSDL2-2.0.so.0” … there are
games in the field expecting this.

Wasn’t the binary compatability been broken multiple times recenty?

I should say “there will be games in the field expecting this.”

The Valve Runtime is providing this SONAME, and we expect Steam-based
titles will use it.

An unresolved symbol isn’t any better than an .so not found.

True, and when SDL2 is officially locked down, binary compatibility will
be law, just like we did for SDL 1.2 over the course of a decade.

–ryan.On 3/2/13 7:04 PM, Alexander Sabourenkov wrote:

On Sun, Mar 3, 2013 at 2:50 AM, Ryan C. Gordon <@icculus> wrote:

The library SONAME and filename should be “libSDL2-2.0.so.0” …
there are
games in the field expecting this.

Wasn’t the binary compatability been broken multiple times recenty?

I should say “there will be games in the field expecting this.”

The Valve Runtime is providing this SONAME, and we expect Steam-based
titles will use it.

An unresolved symbol isn’t any better than an .so not found.

True, and when SDL2 is officially locked down, binary compatibility will
be law, just like we did for SDL 1.2 over the course of a decade.

–ryan.

Okay, this patch should make the CMake build behave a bit more like the
autotools one. It emulates libtool’s “release” option for the shared
library, and leaves the static library as libSDL2.a, which should match
the autotools build.

What it doesn’t do is create a symlink libSDL2.so -> libSDL2-2.0.so.
CMake has no convenient way of doing this, AFAICT. Perhaps something
could be hacked together with “cmake -E create_symlink”, but my CMake-fu
needs more work.

– David


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdl2-cmake-libtool-release.patch
Type: text/x-patch
Size: 1705 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130303/a8330de5/attachment.binOn 03/03/13 09:49, Ryan C. Gordon wrote:

On 3/2/13 7:04 PM, Alexander Sabourenkov wrote:

On Sun, Mar 3, 2013 at 2:50 AM, Ryan C. Gordon wrote:

I should say “there will be games in the field expecting this.”

The Valve Runtime is providing this SONAME, and we expect Steam-based titles
will use it.

I bought a game on linux steam specifically to see what are they
thinking and got launch failures not even acknowledged by the UI.
Reason? They bundled some (outdated by definition) libstdc++ which
prevented Mesa GL drivers from loading. This isn’t even an yet
unreleased library and they already messed stuff up.

Thus I am sure whatever Valve folks, or people releasing on Steam for
linux do for about half a year at least must be taken with
overwhelming amounts of salt. They also have magnificent patching
process. At least it insists on downloading tens of megabytes about
every couple of days.

I understand that I don’t have any idea what are Valve requirements
for a linux release. Maybe there are none whatsoever.

However, let this critical binary-compatability decision which would
not be possible to revert not be driven by some early adopters, which
I suspect never even hinted anything about.

True, and when SDL2 is officially locked down, binary compatibility will be
law, just like we did for SDL 1.2 over the course of a decade.

Yup, and library soname is as much a binary compatibility issue as
method signatures are. Why does it need be locked before that?On Sun, Mar 3, 2013 at 5:49 AM, Ryan C. Gordon wrote:

./lxnt