Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

SDL2 for older MacOS X

lauland

lauland

macrumors member
Original poster
Jan 20, 2025
81
36
@barracuda156, I've created this thread to continue our discussions from https://forums.macrumors.com/threads/sdl2-for-mac-os-9-system-7-early-wip.2455196/

I figure this'll be a good place to discuss SDL2 on basically all unsupported versions of MacOS X, both PowerPC and Intel.

I took a look at your patches, and they are very good. The fact that you've got your own fork of MacPorts is even better, and very impressive!

I will probably need some guidance to set up a build tree based on your sources. It looks like I'd need to use your variant of MacPorts, and then could get the libsdl2-powerpc and libsdl2-legacy packages. Is that correct? If you have the time, let me know how I'd set this up. (I'm familiar with MacPorts and Homebrew in general, so I likely won't need much hand holding).
 
  • Like
Reactions: barracuda156
I have the source tree I'm using for MacOS 9 SDL2, which is based on SDL 2.30.x, and using it to build for MacOS 9, modern MacOS X and Linux, but wanted to see the oldest version of MacOS X that is officially supported.

Numerous places in the source it detects and rejects any SDK older than 10.7, this would imply that 10.7 is supported, but that doesn't seem to be the case. I was able to build and run fine on 10.8, and THAT seems to be the oldest version that is still officially supported. (FYI I could see there is a subtle problem with random number generation, or something, on 10.8, as the testsprite2 demo runs fine, but shows a definite odd pattern in movement it shouldn't).

Trying to build on 10.7 showed problems with language support, namely new autorelease and __bridge language syntax, the older compiler probably can't understand, but the older 10.7 SDK is also missing quite a bit. It looks like the last available XCode for 10.7 contains a much newer SDK, but I don't know how to use it from the command line...and it's not worth the trouble, anyway.

Obviously there were other problems even beyond that, all of which it looks like you've run into and already have decent patches for.

I don't know how much I'll be able to actually help, as I can't claim to have good Cocoa and Objective C skills, but just letting you bounce ideas off my head may be useful! I've been plumbing around in the guts of SDL2 quite a bit lately.

I would think one possible future direction would be instead of patches, "new" different drivers, something like a "cocoalegacy" or whatever, which would live alongside the existing cocoa drivers, but not use or be related to them, similar to my "macosclassic" ones. These would be either based on an old version of the cocoa drivers, or the current ones with your patches. Regardless, this is just an idea/sugestion, but it'd be the direction I'd personally take if I were attempting this myself.
 
lauland said:
@barracuda156, I've created this thread to continue our discussions from https://forums.macrumors.com/threads/sdl2-for-mac-os-9-system-7-early-wip.2455196/

I figure this'll be a good place to discuss SDL2 on basically all unsupported versions of MacOS X, both PowerPC and Intel.

I took a look at your patches, and they are very good. The fact that you've got your own fork of MacPorts is even better, and very impressive!

I will probably need some guidance to set up a build tree based on your sources. It looks like I'd need to use your variant of MacPorts, and then could get the libsdl2-powerpc and libsdl2-legacy packages. Is that correct? If you have the time, let me know how I'd set this up. (I'm familiar with MacPorts and Homebrew in general, so I likely won't need much hand holding).
Click to expand...

-powerpc one is just ahead of what mainstream MacPorts has, but should work as a drop-in replacement. You can run `diff -u` for two portfiles to verify.
-legacy one (Cocoa) is not in MacPorts (it was in Ken’s overlay earlier), and libsdl2 port (a stub in our case) has been modified to allow using either.

I think you are better off using my fork on powerpc, even if you build everything from source, since at least some relevant bugs are already fixed. But in most cases what matters is updated portfiles, not the base. (However if you just add the whole of my ports to a standard MacPorts, not everything will work, starting from indexing, since some portgroups won’t be found.)

Specifically for SDL either will do, perhaps. If you use X11 on 10.6, review what xorg-server-legacy does, you may (or may not) need my version.
 
lauland said:
I have the source tree I'm using for MacOS 9 SDL2, which is based on SDL 2.30.x, and using it to build for MacOS 9, modern MacOS X and Linux, but wanted to see the oldest version of MacOS X that is officially supported.

Numerous places in the source it detects and rejects any SDK older than 10.7, this would imply that 10.7 is supported, but that doesn't seem to be the case. I was able to build and run fine on 10.8, and THAT seems to be the oldest version that is still officially supported. (FYI I could see there is a subtle problem with random number generation, or something, on 10.8, as the testsprite2 demo runs fine, but shows a definite odd pattern in movement it shouldn't).

Trying to build on 10.7 showed problems with language support, namely new autorelease and __bridge language syntax, the older compiler probably can't understand, but the older 10.7 SDK is also missing quite a bit. It looks like the last available XCode for 10.7 contains a much newer SDK, but I don't know how to use it from the command line...and it's not worth the trouble, anyway.

Obviously there were other problems even beyond that, all of which it looks like you've run into and already have decent patches for.

I don't know how much I'll be able to actually help, as I can't claim to have good Cocoa and Objective C skills, but just letting you bounce ideas off my head may be useful! I've been plumbing around in the guts of SDL2 quite a bit lately.

I would think one possible future direction would be instead of patches, "new" different drivers, something like a "cocoalegacy" or whatever, which would live alongside the existing cocoa drivers, but not use or be related to them, similar to my "macosclassic" ones. These would be either based on an old version of the cocoa drivers, or the current ones with your patches. Regardless, this is just an idea/sugestion, but it'd be the direction I'd personally take if I were attempting this myself.
Click to expand...

It is generally quite common that stuff is released without being tested even on presumably supported configurations and some checks are added based on “I think it will work” (and then it works the opposite way, because underscore-prefixed macros are not defined and expand to 0, for example).

I never tried to build SDL2 on 10.7+ though with an idea to fix a newer version. I also do not have 10.7 VM.

Since x86 systems use clang by default, it is pretty meaningless to work on 10.7+ with an aim to improve something for 10.6 or earlier.

As long as blocks are not used, ObjC syntax can be fixed for gcc, perhaps we could try Copilot suggestions there. I recall with 2.0.9 I had to comment out a lot of Cocoa code, and likely it is not what we want at all. If blocks are used heavily, then the only realistic option is to wait for gcc upstream to fix it LOL
 
OK, I took a closer look at your macports and build environment. It is radically different from the approach I am taking, to say the least, which is just building from a simple source tree, uploading the whole tree to MG but also having a git repo. (Obviously that is all I can do since my project is for MacOS 7/8/9).

I'm not really interested in 10.6 on PowerPC, unfortunately. First, obviously I'm doing heavy development for classic Mac, so I need Classic and am stuck in 10.4, unless I want to do vm's or set up different machines, etc, which I'd like to avoid. I also am personally leery of doing development on a non-standard os, as it could add many unknown variables. But I do understand your and other people's interest in it, it's just not for me.

With that said, if I'm going to look further into this there's a couple ways for me start taking a look. The obvious way would be for me to set up a 10.6 ppc machine, install macports with your overlay and get the packages that way. I could do this, but it would take up a lot of time and effort on my part, just setting the machine up, etc etc. I'd rather avoid this, if possible.

The easier way (for me at least) would be if you had a copy of a raw tree that builds, outside of a macports environment. My development work is just Makefile based, and having to deal with macports on ppc (on an os I don't already have) and building inside it is so different that this would save me a huge amount of time. (Leaving aside the question of how I'd get it to build if I don't have 10.6 ppc for now).

So it isn't entirely clear what form helping you should take, since our projects are so drastically different. I actually would be interested in looking into SDL2 on 10.4, ideally, maybe, building out of the same tree I'm using for MacOS 9. It's possible using your patches I could do that, and then we could trade what we each find out, fixing bugs, but having separate source trees otherwise. This may even be unavoidable if there are too many differences between 10.4 and 10.6, or if you are focused on 10.6, etc.
 
lauland said:
OK, I took a closer look at your macports and build environment. It is radically different from the approach I am taking, to say the least, which is just building from a simple source tree, uploading the whole tree to MG but also having a git repo. (Obviously that is all I can do since my project is for MacOS 7/8/9).

I'm not really interested in 10.6 on PowerPC, unfortunately. First, obviously I'm doing heavy development for classic Mac, so I need Classic and am stuck in 10.4, unless I want to do vm's or set up different machines, etc, which I'd like to avoid. I also am personally leery of doing development on a non-standard os, as it could add many unknown variables. But I do understand your and other people's interest in it, it's just not for me.

With that said, if I'm going to look further into this there's a couple ways for me start taking a look. The obvious way would be for me to set up a 10.6 ppc machine, install macports with your overlay and get the packages that way. I could do this, but it would take up a lot of time and effort on my part, just setting the machine up, etc etc. I'd rather avoid this, if possible.

The easier way (for me at least) would be if you had a copy of a raw tree that builds, outside of a macports environment. My development work is just Makefile based, and having to deal with macports on ppc (on an os I don't already have) and building inside it is so different that this would save me a huge amount of time. (Leaving aside the question of how I'd get it to build if I don't have 10.6 ppc for now).

So it isn't entirely clear what form helping you should take, since our projects are so drastically different. I actually would be interested in looking into SDL2 on 10.4, ideally, maybe, building out of the same tree I'm using for MacOS 9. It's possible using your patches I could do that, and then we could trade what we each find out, fixing bugs, but having separate source trees otherwise. This may even be unavoidable if there are too many differences between 10.4 and 10.6, or if you are focused on 10.6, etc.
Click to expand...

You do not have to use MacPorts, of course. However you will need to have a modern compiler (I don’t think gcc-4.0 or gcc-4.2 will work) and required dependencies (for X11 backend).
MacPorts does not do something exclusive, everything can be reproduced manually. (IMO that is far more complicated in most cases – there are exceptions though).

There is also nothing exclusive to 10.6 ppc in libsdl2 port. I built it on 10.5 just a week ago or so, and earlier I verified the build on Tiger (that may or may not work now, but should be easily fixable for X11).

You could actually apply patches to a git tree with `git apply`. But I will try to do that tonight and share a link then.
 
@lauland And there is no contradiction between working to fix it for 10.4 and 10.6, since the primary constraint is identical (no clang = no support for modern ObjC), and SDK capabilities of 10.4 are a subset of those of 10.6.

If you do not have a working C11-capable compiler and do not want to use MacPorts to have it, maybe @cellularmitosis can give an advice. On 10.5 you can just build gcc10 from Iain’s tree with Xcode tools.
 
So, I 'm probably wrong, but from reading the portfiles, I'm guessing macports pulls the official/original sources for whatever version a package is based on (and obviously all dependencies), does any patches if they are included, and has the information to pass to configure and make...then builds it, correct? ie If some person were crazy enough, they could reproduce this by hand, if they were just too hard headed.

I have gcc 8.5, that came along with TigerBrew which I needed for building Retro68 (I use its gcc 9.1 for classic to build SDL2 for MacOS 7/8/9), regardless, getting a good enough compiler isn't an issue, if what I have isn't already. (Getting all dependencies for it too, obviously, as needed).

Ok...so I believe I'm understanding the three packages in your macports, please correct if wrong...
libsdl2 (no patches)
libsdl2-legacy (old cocoa)
libsdl2-powerpc (new x11)...this is the one, correct?
(with libsdl2-snowleopard in the official macports being the last cocoa for 10.6).

Apologies, if I seem hard headed about macports...
 
lauland said:
So, I 'm probably wrong, but from reading the portfiles, I'm guessing macports pulls the official/original sources for whatever version a package is based on (and obviously all dependencies), does any patches if they are included, and has the information to pass to configure and make...then builds it, correct? ie If some person were crazy enough, they could reproduce this by hand, if they were just too hard headed.

I have gcc 8.5, that came along with TigerBrew which I needed for building Retro68 (I use its gcc 9.1 for classic to build SDL2 for MacOS 7/8/9), regardless, getting a good enough compiler isn't an issue, if what I have isn't already. (Getting all dependencies for it too, obviously, as needed).

Ok...so I believe I'm understanding the three packages in your macports, please correct if wrong...
libsdl2 (no patches)
libsdl2-legacy (old cocoa)
libsdl2-powerpc (new x11)...this is the one, correct?
(with libsdl2-snowleopard in the official macports being the last cocoa for 10.6).

Apologies, if I seem hard headed about macports...
Click to expand...

Yes, you can reproduce by hand whatever MacPorts does. Portfiles (+portgroups) just provide recipes of what is passed to a given build system (and handle fetching, patching and installing). You can also switch between MacPorts and manual building on the go, though this is obviously not a recommended way generally (but can be useful for debugging).

I never used gcc8–9 (besides satisfying a nominal dependency for libgccX), but I think it should work fine. Nothing in SDL-related stuff require C++23.

P. S. libsdl2 is a stub in our case, nothing there besides a registry entry. libsdl2-powerpc is the version which tracks releases of 2.x branch and uses X11 (Cocoa is disabled).
 
Last edited:
Ok, was able to build X11 version with opengl disabled, on g4 running 10.4. Non-opengl tests seem to work fine. (opengl ones were, of course, not even built). I used SDL2 2.32.4 with patches and configure options from the Portfile.

NOTE: I wanted to see how the native gcc 4.0.1 fared. It worked fine, but guess might see problems if I'd been building the cocoa driver, eh?

FYI I had to comment out line 118 in include/SDL_platform.h. This checks MAC_OS_X_VERSION_MIN_REQUIRED < 1040 (as patched). On a g5 or intel this is set to MAC_OS_X_VERSION_10_4 in /usr/include/AvailabilityMacros.h, but on a 32 bit ppc this is set to MAC_OS_X_VERSION_10_1 sadly.

Will try building with opengl next. Will look into the mesa vs apple's thing.
 
  • Like
Reactions: barracuda156
lauland said:
Ok, was able to build X11 version with opengl disabled, on g4 running 10.4. Non-opengl tests seem to work fine. (opengl ones were, of course, not even built). I used SDL2 2.32.4 with patches and configure options from the Portfile.

NOTE: I wanted to see how the native gcc 4.0.1 fared. It worked fine, but guess might see problems if I'd been building the cocoa driver, eh?

FYI I had to comment out line 118 in include/SDL_platform.h. This checks MAC_OS_X_VERSION_MIN_REQUIRED < 1040 (as patched). On a g5 or intel this is set to MAC_OS_X_VERSION_10_4 in /usr/include/AvailabilityMacros.h, but on a 32 bit ppc this is set to MAC_OS_X_VERSION_10_1 sadly.

Will try building with opengl next. Will look into the mesa vs apple's thing.
Click to expand...

Cool! I don’t remember now what was the issue with Xcode gcc and SDL, there was probably some reason not to use it. Need to check that.

We probably should just remove that check from SDL platforms header, it serves no good purpose anyway.
 
Hmm, it actually builds fine with gcc-4.2. Just updated to 2.32.6. No idea why it was blacklisted, but FWIW it seems to work fine now.
 
On my 10.4 g4, I enabled opengl (Apple's, that came with their X11) for the x11 SDL build I have working. It would then hang inside X11_GL_InitExtensions() in SDL_x11opengl.c at the line "_this->gl_data->glXMakeCurrent(display, None, NULL);". I commented this line out, just to see, as it looks like it is just trying to reset the driver's context, and tests now run. Can't say how stable it may be, or if this is something specific to my particular setup, and not sure why it would hang there.

I'll also look into mesa.
 
  • Like
Reactions: barracuda156
lauland said:
On my 10.4 g4, I enabled opengl (Apple's, that came with their X11) for the x11 SDL build I have working. It would then hang inside X11_GL_InitExtensions() in SDL_x11opengl.c at the line "_this->gl_data->glXMakeCurrent(display, None, NULL);". I commented this line out, just to see, as it looks like it is just trying to reset the driver's context, and it now runs. Can't say how stable it may be, or if this is something specific to my particular setup, and not sure why it would hang there.

I'll also look into mesa.
Click to expand...

Awesome, thank you very much for looking into this. I will rebuild with your fixes, once you consider it ready for testing.
If we get OpenGL working correctly, that will probably solve some issues with mpv and vlc.

P. S. You used not OpenGL from the framework, but dylibs from optional X11 components? I had troubles with Apple X11 co-existing with MacPorts X11 (I actually thought GTK is broken on powerpc, while it was just an effect of conflict), so wiped out the Apple one. Hopefully the same fix will work with MacPorts one (or otherwise we/me need to find a way for them to co-exist).
 
I wanted to make as few changes as needed to get it working, on as plain vanilla 10.4 system as possible, without installing macports or anything else, other than XCode, of course. I applied the "000" patches, but not the opengl_apple or wayland ones.

I passed "--x-includes=/usr/X11R6/include" and "--x-libraries=/usr/X11R6/lib" to configure, but let it choose whatever prefix it wanted, which ended up being "/usr/local", which is fine if someone doesn't have macports.

I'm not sure why, I even grep'd for it in the configure files, Makefiles, and source, but it still wanted to look in "/opt/local" for some things. Because of this I had to do "ln -s /usr/X11R6 /opt/local/X11" because it wasn't finding X11 for part of the build, ie it didn't fully use the X11 path I set with configure. (So a bug there).

Obviously if I had macports installed, it'd find the macports X11 in "/opt/local"...but this might not be great because it might be attempt to use BOTH Apple's and macport's X11, so maybe a conflict if you have both installed.

There's still a bug building testnative in "test/configure", and I had to add "-L/opt/local/X11/lib" (could have used "-L/usr/X11R6/lib") for it, but probably not worth fixing, unless it doesn't build for you.

Regardless, after all that, everything builds, installs and works. (With that single, probably unncessary, line commented out I mentioned).

I believe it is stable, but haven't really put it through the rigors. Some SDL2 things that use OpenGL could be built to test further.

----

Because this is an X11 build, it is not using the OpenGL framework directly, but only X11's support, so "/opt/local/X11/lib/libGL.a", etc. (Or, of course, alternately, in "/usr/X11R6/lib").

I would definitely suggest avoiding having both Apple's and macport's X11 on the same machine, as there could be confusion over which parts it linked with and where. And, if anything is majorly different in the two, it would likely be OpenGL support, among other things.

----

I decided not to look at mesa for the time being, as meson requires various python packages, etc, I just didn't want to deal with, and since Apple's OpenGL seems to work. I do definitely want to look into it for MacOS 7/8/9 and have done a little tentative work using it on M68k for OpenGL.

I'll probably look at the ancient 2.0.3 cocoa build with its patches at some point.
 
  • Like
Reactions: barracuda156
The 2.0.3 "legacy" port builds fine and, other than being based on quite an old version of SDL2, works well. Coreaudio and cocoa work using far older drivers than in the current version. OpenGL is done via Cocoa, so completely different libs and api than the X11 build. It will in general be faster, more Mac like, and have more features. X11 support for that build needs a little work, but since the Cocoa driver is fully functional, probably not worth the trouble of fixing. Joystick support using the patches from the port worked fine.

As a personal project I will be looking into seeing if it is possible to use the older Cocoa, CoreAudio and joystick drivers in a more recent version of SDL2. I did an initial attempt, but SDL2 has changed quite a bit between 2.0 and 2.30 and it will take some work.

----

Noting that the Coreaudio driver is broken in the X11 build mentioned previously, and disabled in the portfile, so that build has no audio support. This is not easily fixable for non-recent versions of MacOS X, but the older driver from 2.0.3 could be used (once it is working).
 
Last edited:
  • Like
Reactions: barracuda156
I'm going to post my builds of both versions of SDL2 on MG, because SDL2 for Tiger (and similar older OS X's) isn't easy to obtain outside of macports, and even those builds are limited (see above posts). This is especially useful as what I did didn't require anything other than a standard Tiger and XCode install, with the small number of fixes and configure tweaks I did.

I will include full attribution to where the source, patches, and configure information, originated, from macports and http://macos-powerpc.org, and specify that I was not the originator of any of it, but only found out what was needed to build them by hand.

----

I will be folding in the patches from the X11 2.32.4 build into my "SDL2 for MacOS 7/8/9" tree, so the same source can be used to build both for those OS's and for older MacOS X's. I'll also see about mantaining compatibility with modern MacOS X and Linux.

As mentioned above, I'll separately be looking into getting the older 2.0.3 CoreAudio, Cocoa and joystick drivers to work with 2.32.4. Doing this, and maintaining modern MacOS X compatibility, may require having three "branches", or at least separate drivers: "Legacy, ie 10.4", "PowerPC-or-newer-than-10.4-but-still-old" and "Modern". Adding complication, but probably worth the trouble to be able to support practically all Mac OS's.
 
  • Like
Reactions: Jazzzny and barracuda156
lauland said:
I wanted to make as few changes as needed to get it working, on as plain vanilla 10.4 system as possible, without installing macports or anything else, other than XCode, of course. I applied the "000" patches, but not the opengl_apple or wayland ones
Click to expand...

Wayland patches are inconsequential, since SDL does not acknowledge Wayland on macOS, as of now. Something more needs to be fixed, and I had no time for that so far.
Also, for Wayland to work we need a working compositor. The only one existing is Owl, but it is in experimental stage. See:
github.com

Build error: `OwlShmBuffer.m: error: incompatible type for argument 2 of ‘CGContextDrawImage’` · Issue #13 · owl-compositor/owl

The first error was OwlKnownClientsManager.m:46: error: ‘for’ loop initial declaration used outside C99 mode; after passing -std=c99, the build proceeded, but failed here: ccache /usr/bin/gcc-4.2 /...
github.com github.com
github.com

3 issues encountered with GTk3 apps using the wayland GDK backend · Issue #20 · owl-compositor/owl

Continued from issue #13 ... I've built Owl and also managed to build GTk3 with the Wayland backend. I notice 2 things: GTk3 uses wl_pointer_add_listener() to get pointer events, notably clicks. So...
github.com github.com
 
lauland said:
I would definitely suggest avoiding having both Apple's and macport's X11 on the same machine, as there could be confusion over which parts it linked with and where. And, if anything is majorly different in the two, it would likely be OpenGL support, among other things.
Click to expand...

The problem with Apple X11 is that it is present on one of default search paths, so anything can randomly pick it, and we get unpredictably broken ports. In principle, simply moving it elsewhere, to some non-default location, gonna solve the problem.
Then the only issue remaining will be reproducibility: depending on something which is neither part of the OS nor installable via MacPorts, so it is not guaranteed to be present.
 
lauland said:
The 2.0.3 "legacy" port builds fine and, other than being based on quite an old version of SDL2, works well. Coreaudio and cocoa work using far older drivers than in the current version. OpenGL is done via Cocoa, so completely different libs and api than the X11 build. It will in general be faster, more Mac like, and have more features. X11 support for that build needs a little work, but since the Cocoa driver is fully functional, probably not worth the trouble of fixing. Joystick support using the patches from the port worked fine.

As a personal project I will be looking into seeing if it is possible to use the older Cocoa, CoreAudio and joystick drivers in a more recent version of SDL2. I did an initial attempt, but SDL2 has changed quite a bit between 2.0 and 2.30 and it will take some work.
Click to expand...

Regardless of stability on its own, the issue with 2.0.x is that it is likely cannot be used with anything else, since API deviated substantially since then. (Or otherwise every dependency needs to be hacked to be able to use it.)

So yeah, hopefully Cocoa can be resorted into current versions. I am not even sure MacPorts’ libsdl2-snowleopard is any usable either.

lauland said:
Noting that the Coreaudio driver is broken in the X11 build mentioned previously, and disabled in the portfile, so that build has no audio support. This is not easily fixable for non-recent versions of MacOS X, but the older driver from 2.0.3 could be used (once it is working).
Click to expand...

CoreAudio is disabled only for 10.4. It works fine otherwise in modern SDL2.
 
It looks like the path to libGL.a is hard coded in the X11 driver, which is why I had to put a link from my install of Apple's X11 in /opt/local. I don't know if there's a simple way around this, and if someone has Apple's and not macports' X11, making them create a link like that is trivial, and will make life easier for them anyway...if they use a macports port that assumes their have the macports' X11, it should then work fine if they only have Apple's X11. (Assuming they understand what is is they are doing). This is goofy, but...oh well.

It might be possible the dylib search path will find it if the driver doesn't specify a path, if Apple's X11 is in it, but I have no idea if it is by default or not. Again, probably not worth the time even to look into. If you don't have macports, having that link is just a good workaround.
 
I saw the patch, what I am saying is it is unfortunate it must be specified at SDL2 build time, it would be better if it were detectable at runtime.

If it must be dependent on the SDL2 build the user has, it might as well be standardized on /opt/local which macports uses. Even if I don't have macports X11, having a link to where it expects lets me run ports built against it.
 
  • Like
Reactions: barracuda156
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back