Question for Linux distribution maintainers

SDL Development
1

Hey, SDL 1.3 is getting to the point where I want to start making
official alpha releases publicly available for testing. One of the
things preventing that is how to set up the SDL packages so that they
can coexist with SDL 1.2.

Do you guys have any suggestions on the best way to set up SDL 1.3 to
install cleanly next to SDL 1.2 and allow the user to pick which
library they want to link with? There is also the question of how to
handle the ancillary libraries like SDL_image, which are source
compatible with both, but need to be compiled to separate packages for
each.

Thoughts?–
? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

2

Haven’t there been ABI changes? I would expect distro maintainers to
simply rename the SDL 1.3 libs and package SDL 1.3 separately.On Sat, Jul 17, 2010 at 11:15 AM, Sam Lantinga wrote:

Do you guys have any suggestions on the best way to set up SDL 1.3 to
install cleanly next to SDL 1.2 and allow the user to pick which
library they want to link with? ?There is also the question of how to
handle the ancillary libraries like SDL_image, which are source
compatible with both, but need to be compiled to separate packages for
each.

Thoughts?

–
? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

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

–
http://codebad.com/

3

But what do they name it? And how do you name SDL_ttf 2.0 which is built
with SDL 1.3? Is it okay to put libs in a subfolder like the includes? I
think that would be plenty clean. I’d put the includes in include/SDL-1.3
and the libs in lib/SDL-1.3.

Jonny DOn Sun, Jul 18, 2010 at 2:49 PM, Donny Viszneki <donny.viszneki at gmail.com>wrote:

Haven’t there been ABI changes? I would expect distro maintainers to
simply rename the SDL 1.3 libs and package SDL 1.3 separately.

On Sat, Jul 17, 2010 at 11:15 AM, Sam Lantinga wrote:

Do you guys have any suggestions on the best way to set up SDL 1.3 to
install cleanly next to SDL 1.2 and allow the user to pick which
library they want to link with? There is also the question of how to
handle the ancillary libraries like SDL_image, which are source
compatible with both, but need to be compiled to separate packages for
each.

Thoughts?

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

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

–
http://codebad.com/

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

4

+1On Sunday 18 July 2010 12:01, Jonathan Dearborn wrote:

I’d put the includes in include/SDL-1.3
and the libs in lib/SDL-1.3.

5

But what do they name it?

They’ll name the new SDL libs whatever SDL names them. There is only a
problem if SDL does not take the initiative to rename when backward
compatibility is broken.

I’ve used a few libs on Debian and Ubuntu which can’t coexist easily
using what’s in the standard repositories. You’re given the option to
use one or the other, but you aren’t given an option on these systems
to have them coexist and set up which applications use which ones.

Some applications can coexist in the sense that the packages can be
unarchived into your filesystem, but Debian/Ubuntu has a layer on top
of them that allows you to choose which one is the “active” one. It’s
an imperfect solution for some people, however, as applications which
are not made specifically to support multiple simultaneous versions of
installed software components cannot see through this layer and can
only use the “active” packages.

And how do you name SDL_ttf 2.0 which is built with SDL 1.3?

That is a good question.

Is it okay to put libs in a subfolder like the includes?

Most dynamic linkers will not agree with this idea.

?I
think that would be plenty clean.? I’d put the includes in include/SDL-1.3
and the libs in lib/SDL-1.3.

I believe the headers are backward compatible, so there’s no problem with them.On Sun, Jul 18, 2010 at 3:01 PM, Jonathan Dearborn wrote:

–
http://codebad.com/

6

Hey, SDL 1.3 is getting to the point where I want to start making
official alpha releases publicly available for testing. ?One of the
things preventing that is how to set up the SDL packages so that they
can coexist with SDL 1.2.

Do you guys have any suggestions on the best way to set up SDL 1.3 to
install cleanly next to SDL 1.2 and allow the user to pick which
library they want to link with? ?There is also the question of how to
handle the ancillary libraries like SDL_image, which are source
compatible with both, but need to be compiled to separate packages for
each.

Thoughts?

Well, I did a “locate libSDL” on Ubuntu 10.4 and this is what I got:

/usr/lib/libSDL-1.2.so.0
/usr/lib/libSDL-1.2.so.0.11.3
/usr/lib/libSDL.a
/usr/lib/libSDL.la
/usr/lib/libSDL.so
/usr/lib/libSDL_image-1.2.so.0
/usr/lib/libSDL_image-1.2.so.0.8.2
/usr/lib/libSDL_mixer-1.2.so.0
/usr/lib/libSDL_mixer-1.2.so.0.2.6
/usr/lib/libSDL_net-1.2.so.0
/usr/lib/libSDL_net-1.2.so.0.0.7
/usr/lib/libSDLmain.a

It looks like you can just change 1.2 to 1.3 to handle the problems
with the .so files.

/usr/lib/libSDL-1.3.so.0
/usr/lib/libSDL-1.3.so.0.11.3
/usr/lib/libSDL.a
/usr/lib/libSDL.la
/usr/lib/libSDL.so
/usr/lib/libSDL_image-1.3.so.0
/usr/lib/libSDL_image-1.3.so.0.8.2
/usr/lib/libSDL_mixer-1.3.so.0
/usr/lib/libSDL_mixer-1.3.so.0.2.6
/usr/lib/libSDL_net-1.3.so.0
/usr/lib/libSDL_net-1.3.so.0.0.7
/usr/lib/libSDLmain.a

The trouble seems to be with the .a and .la files. I’d just change the
prefix for all SDL related files form libSDL to libSDL13 and then
later to libSDL20 and drop the suffix so that for 1.3 the file names
would be:

/usr/lib/libSDL13.so.0
/usr/lib/libSDL13.so.0.11.3
/usr/lib/libSDL13.a
/usr/lib/libSDL13.la
/usr/lib/libSDL13.so
/usr/lib/libSDL13_image.so.0
/usr/lib/libSDL13_image.so.0.8.2
/usr/lib/libSDL13_mixer.so.0
/usr/lib/libSDL13_mixer.so.0.2.6
/usr/lib/libSDL13_net.so.0
/usr/lib/libSDL13_net.so.0.0.7
/usr/lib/libSDL13main.a

Doing something like this would allow many versions of SDL to coexist
and put the name of the version of SDL used to build an add on
directly in the name of the add on file.

I will admit that it is sort of ugly, but it should work.

Bob PendletonOn Sat, Jul 17, 2010 at 10:15 AM, Sam Lantinga wrote:

–
? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

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

–
±----------------------------------------------------------

7

Do you guys have any suggestions on the best way to set up SDL 1.3 to
install cleanly next to SDL 1.2 and allow the user to pick which
library they want to link with? There is also the question of how to
handle the ancillary libraries like SDL_image, which are source
compatible with both, but need to be compiled to separate packages for
each.

Well, looking at my /usr/include and /usr/lib I’d do the following:

/usr/include/SDL // SDL 1.2 already exists (on Ubuntu)
/usr/include/SDL-1.3 // SDL 1.3 headers

The libraries at the moment are symlinked from:

libSDL.so → libSDL-1.2.so.0.11.3 (so from libSDL.so to the current version)

Obviously you don’t wanna change that, or you’ll break a load of apps, so I
guess just add:

libSDL-1.3.so → libSDL-1.3.so.x.y.z (symlink to the current 1.3 version)

Where it comes to libraries that are compatible with both, I guess compiling
versions for both and postfixing 1.3 to the end e.g.

libSDL_image.so → libSDL_image-1.2.so.0.8.2
libSDL_image-1.3.so → libSDL_image-1.3.so.x.y.z

Then there would be packages for

libsdl-image-1.2 //Exists on Ubuntu
libsdl-image-1.3 // New version linked to libSDL-1.3

So basically, keep everything the same for 1.2, postfix -1.3 to everything
that needs it. The libSDL.so will need to be named differently otherwise it
will cause a load of headaches and breakage. Of course that means apps that
use SDL 1.3 will need to link to libSDL-1.3.so but I don’t think that’s an
issue.

Luke.

8

Of course that means apps that use SDL 1.3 will need to link to
libSDL-1.3.so but I don’t think that’s an issue.

Forgive me if this is incorrect but isn’t one of the points of LGPL to allow
a user to change the library linked without recompiling? (If the ABI is
conforming)On 21 July 2010 11:02, Luke Benstead wrote:

9

Of course that means apps that use SDL 1.3 will need to link to
libSDL-1.3.so but I don’t think that’s an issue.

Forgive me if this is incorrect but isn’t one of the points of LGPL to
allow a user to change the library linked without recompiling? (If the ABI
is conforming)

Perhaps I have misunderstood, is 1.3 completely backwards compatible with
1.2? I was under the impression it wasn’t.

Luke.On 21 July 2010 12:43, liam mail <liam.list at googlemail.com> wrote:

On 21 July 2010 11:02, Luke Benstead <@Luke_Benstead> wrote:

10

Perhaps I have misunderstood, is 1.3 completely backwards compatible with
1.2? I was under the impression it wasn’t.

You haven’t missed anything. A recompile with the 1.3 headers is necessary.On Thu, Jul 22, 2010 at 6:37 AM, Luke Benstead wrote:

On Wed, Jul 21, 2010 at 7:43 AM, liam mail <liam.list at googlemail.com> wrote:

Forgive me if this is incorrect but isn’t one of the points of LGPL to allow
a user to change the library linked without recompiling? (If the ABI is
conforming)

Your perception that the LGPL provides the open source community with
the capability to modify the LGPL-licensed components of proprietary
software is completely 100% correct.

This does not change the fact that SDL 1.3 is really a new branch of
SDL, and is not ABI compatible with SDL 1.2. A recompile will be
necessary to port an application binary from SDL 1.2 branch to SDL 1.3
branch.

–
http://codebad.com/