SDL2 for older MacOS X

[lauland]

@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).

 

[lauland]

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.

 

[barracuda156]

@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).

-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.

 

[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.

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

 

[lauland]

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.

 

[barracuda156]

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.

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.

 

[barracuda156]

@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.

 

[lauland]

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...

 

[barracuda156]

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...

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).