SDL 1.2 build still broken on Macos X 10.9 one year later

SDL Development
1

Guys,

I have reported this issue many times, I wonder if it is because nobody
cares or you are too busy but I will make one last attempt:

Downloading SDL-1.2.15.tar.gz is broken on MacOS X 10.9. On make we get the
following error:

*error: *unknown type name ‘CGDirectPaletteRef’

The last time I reported the issue I was told it is fixed in Mercurial but
many people don’t know that and many people don’t know how to get the
latest version in Mercurial.

I assume Mercurial branch would eventually make it to the download page but
one year later it is no there. Can you please please fix the tar from
https://www.libsdl.org/download-1.2.php ?

There are so many projects out there that still use SDL 1.2 and it would be
very tedious to port them to SDL 2.0.

Regards,

Fabien

2

I assume Mercurial branch would eventually make it to the download page
but one year later it is no there. Can you please please fix the tar
from Simple DirectMedia Layer - SDL version 1.2.15 (historic) ?

Our intention was to never ever update 1.2 again (except, eventually, to
replace it with a small bridge library that looks like 1.2 to your app
but talks to 2.0), but this is sort of a frustrating situation that
Apple has forced us into in the meantime.

(building on newer SDKs aside, 1.2.15 also depends on Mac OS X to pass a
magic command line to the app that lets us know that we were launched
from the Finder…Mac OS X 10.9 stopped passing that command line, so at
a minimum, existing apps might find themselves running with an
unexpected current working directory…and since this is in SDLmain, the
only way to fix this is relinking the app itself, not even SDL. It’s
infuriating.)

I’ll ask about doing a 1.2.16 again.

–ryan.

3

2014-09-08 1:21 GMT-03:00, Ryan C. Gordon :

(building on newer SDKs aside, 1.2.15 also depends on Mac OS X to pass a
magic command line to the app that lets us know that we were launched
from the Finder…Mac OS X 10.9 stopped passing that command line, so at
a minimum, existing apps might find themselves running with an
unexpected current working directory…and since this is in SDLmain, the
only way to fix this is relinking the app itself, not even SDL. It’s
infuriating.)

Silly question, but I’m curious: how does SDL2 handle that? Is there
some other way to detect it or does SDL2 look at the environment to
attempt to guess?

4

Silly question, but I’m curious: how does SDL2 handle that? Is there
some other way to detect it or does SDL2 look at the environment to
attempt to guess?

We use a different approach now:

 https://hg.libsdl.org/SDL/rev/cfec3f86fba7

If we have no command line arguments, we’re on 10.9 or later, and the
current working directory is “/” then we assume the Finder launched us.

–ryan.

5

I’d suggest that a 1.2.16 or a 1.2.15.1 is warranted just because
there are a lot of binary-only games out there that shouldn’t just
break like that. Sadly because of SDLmain there’s just not a whole
lot that can be done about the Finder issue, save perhaps having SDL
no longer care about Finder, which is somewhat difficult.

Another is that the README says to static link against SDL? That’s
not ideal at all. The BEST solution is to have SDL’s standard
distribution on OS X be as a framework, with a script to produce
compatibility symlinks if necessary for some reason (such as the
inability to use pkgconfig/sdl-config or to use a private framework
in a non-bundle application for testing or somesuch?)

I’m sure someone out there still has a need for SDL to run under X11
on a Mac to use it embedded into some X toolkit as a subwindow object
or ? something, but I’d argue that if you need to do something like
that and you have to jump through enough hoops already that the extra
step involves is fairly minor.

The only possible problem I see is if someone somehow has a
Darwin-based system whose buildsystem cannot understand and use
frameworks. I don’t even know if that’s possible. I kind of doubt
it. Make the leap! :wink: That’s extra work for those of us using
autoconf or cmake as build tools, but that’s not exactly a new
problem and the world could use a couple more real-world working
examples of a suitable solution anyway. :wink:

JosephOn Mon, Sep 08, 2014 at 12:21:10AM -0400, Ryan C. Gordon wrote:

I assume Mercurial branch would eventually make it to the download page
but one year later it is no there. Can you please please fix the tar
from Simple DirectMedia Layer - SDL version 1.2.15 (historic) ?

Our intention was to never ever update 1.2 again (except, eventually,
to replace it with a small bridge library that looks like 1.2 to your
app but talks to 2.0), but this is sort of a frustrating situation
that Apple has forced us into in the meantime.

(building on newer SDKs aside, 1.2.15 also depends on Mac OS X to pass
a magic command line to the app that lets us know that we were
launched from the Finder…Mac OS X 10.9 stopped passing that command
line, so at a minimum, existing apps might find themselves running
with an unexpected current working directory…and since this is in
SDLmain, the only way to fix this is relinking the app itself, not
even SDL. It’s infuriating.)

I’ll ask about doing a 1.2.16 again.

–ryan.

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

6

I’d suggest that a 1.2.16 or a 1.2.15.1 is warranted just because there
are a lot of binary-only games out there that shouldn’t just break like
that. Sadly because of SDLmain there’s just not a whole lot that can be
done about the Finder issue, save perhaps having SDL no longer care
about Finder, which is somewhat difficult.

SDL doesn’t care, it only uses it to set the current working directory
to your game’s installation directory (by default, apps launched by the
Finder have a cwd of “/”). So if a game expects the cwd to be its
install directory, it’s broken and needs to be rebuilt with a newer SDL
(and better yet, be fixed to not depend on this behavior). So it’s not a
total disaster, but it’s definitely a real world scenario.

Another is that the README says to static link against SDL

Huh, that’s terrible advice for LGPL’d code.

–ryan.

7

2014-09-10 19:31 GMT-03:00, Ryan C. Gordon :

Another is that the README says to static link against SDL

Huh, that’s terrible advice for LGPL’d code.

Pretty sure that advice was meant for SDL2 (which is under a more
permissive license). Even then, I’m not sure why can’t the dynamic
library just be included inside the bundle? (but I never made anything
for OSX so I don’t know if that’d work)

8

I’m not sure why can’t the dynamic library just be included inside the
bundle?

You have to setup the @rpath correctly using install_name_tool for that to
work (which is trivial, but not obvious; it breaks ‘cross platform
builds’).

Using a statically linked sdl library is easier I suppose…

The BEST solution is to have SDL’s standard distribution on OS X be as a
framework

Please don’t.

I’d strongly recommend shipping the sdl dylib and all it’s child
dependencies as part of the application bundle; particular the SDL_foo*
libraries with all their dependencies. Application bundles are specifically
designed to allow this to work.

I know that’s somewhat counter to the ‘use system libraries’ approach, but
on most unix systems installing an application doesn’t cause the
application to try to write it’s own copies of libraries into /lib/ :stuck_out_tongue:

Lots of things try to install SDL as a framework as part of their
installation; and extremely irritatingly they will consistently break each
other in my experience.~
Doug.

On Thu, Sep 11, 2014 at 12:22 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

2014-09-10 19:31 GMT-03:00, Ryan C. Gordon :

Another is that the README says to static link against SDL

Huh, that’s terrible advice for LGPL’d code.

Pretty sure that advice was meant for SDL2 (which is under a more
permissive license). Even then, I’m not sure why can’t the dynamic
library just be included inside the bundle? (but I never made anything
for OSX so I don’t know if that’d work)

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

9

You can include application frameworks, and in fact that’s the way SDL is
intended to be distributed, as downloaded from the website.On Thu, Sep 11, 2014 at 6:30 PM, Doug <douglas.linder at gmail.com> wrote:

I’m not sure why can’t the dynamic library just be included inside the
bundle?

You have to setup the @rpath correctly using install_name_tool for that to
work (which is trivial, but not obvious; it breaks ‘cross platform
builds’).

Using a statically linked sdl library is easier I suppose…

The BEST solution is to have SDL’s standard distribution on OS X be as a
framework

Please don’t.

I’d strongly recommend shipping the sdl dylib and all it’s child
dependencies as part of the application bundle; particular the SDL_foo*
libraries with all their dependencies. Application bundles are specifically
designed to allow this to work.

I know that’s somewhat counter to the ‘use system libraries’ approach, but
on most unix systems installing an application doesn’t cause the
application to try to write it’s own copies of libraries into /lib/ :stuck_out_tongue:

Lots of things try to install SDL as a framework as part of their
installation; and extremely irritatingly they will consistently break each
other in my experience.

~
Doug.

On Thu, Sep 11, 2014 at 12:22 PM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

2014-09-10 19:31 GMT-03:00, Ryan C. Gordon :

Another is that the README says to static link against SDL

Huh, that’s terrible advice for LGPL’d code.

Pretty sure that advice was meant for SDL2 (which is under a more
permissive license). Even then, I’m not sure why can’t the dynamic
library just be included inside the bundle? (but I never made anything
for OSX so I don’t know if that’d work)

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

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