SDL 1.2 build still broken on Macos X 10.9 one year later. |
fabiensanglard
|
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 |
|||||||||||
|
SDL 1.2 build still broken on Macos X 10.9 one year later. |
Ryan C. Gordon
Guest
|
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 http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL 1.2 build still broken on Macos X 10.9 one year later. |
Sik
|
2014-09-08 1:21 GMT-03:00, Ryan C. Gordon:
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? _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL 1.2 build still broken on Macos X 10.9 one year later. |
Ryan C. Gordon
Guest
|
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. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL 1.2 build still broken on Macos X 10.9 one year later. |
Joseph Carter
|
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! 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. ;) Joseph On Mon, Sep 08, 2014 at 12:21:10AM -0400, Ryan C. Gordon wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
SDL 1.2 build still broken on Macos X 10.9 one year later. |
Ryan C. Gordon
Guest
|
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.
Huh, that's terrible advice for LGPL'd code. --ryan. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
SDL 1.2 build still broken on Macos X 10.9 one year later. |
Sik
|
2014-09-10 19:31 GMT-03:00, Ryan C. Gordon:
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 http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
SDL 1.2 build still broken on Macos X 10.9 one year later. |
Doug
Guest
|
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...
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/ :P 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 wrote:
|
|||||||||||||||||||||
|
SDL 1.2 build still broken on Macos X 10.9 one year later. |
Sam Lantinga
|
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 wrote:
|
|||||||||||||||||||||
|