SDL2 for older MacOS X

[lauland]

BTW, you could also try this:

sudo port clean lame
sudo port -v -n install lame -simd

Well...f me. I tried again, after making sure TigerBrew wasn't present, and it "just worked", ie lame built fine. So, conflict with TigerBrew in /usr/local/* and I REALLY should have know better! Apologies for my (continuing) insanity. (Talk about "non-reproducible and impossible to debug").

Going to try install of mpv again...see how far I get...

 

[barracuda156]

Well...f me. I tried again, after making sure TigerBrew wasn't present, and it "just worked", ie lame built fine. So, conflict with TigerBrew in /usr/local/* and I REALLY should have know better! Apologies for my (continuing) insanity. (Talk about "non-reproducible and impossible to debug").

Going to try install of mpv again...see how far I get...

Indeed, please wipe out any headers and libs from /usr/local. That location should only be used by Apple software (normally it is not; I think it is used as a temporary location when building OS components). It is a horrible choice from Homebrew to dump its stuff in a system directory, and yes, it can lead to all sort of trouble.

 

[lauland]

Yeah, like I said, I REALLY should have known better, very much mea culpa.

Modern homebrew has moved to /opt/homebrew which is at least sane, but TigerBrew is, of course ancient. It was needed to build Retro68...although in hindsight, everything it needed is also avail via ports. But it was important to at least try and follow the official building instructions.

Anyway, g4 is currently happily building libogg, etc etc...

 

[lauland]

Ha...vim 404 not found:
---> Fetching archive for vim
---> vim-9.1.1324_0+huge.darwin_8.ppc.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified
---> Attempting to fetch vim-9.1.1324_0+huge.darwin_8.ppc.tbz2 from http://macos-powerpc.org/packages/vim
...
mirrors all around the world then fail too
...
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0Error: Failed to fetch vim: The requested URL returned error: 404
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_macos-powerpc.org_macos-powerpc_PPCPorts_ports_editors_vim/vim/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

Tried multiple times, and even just installing vim by itself...I knew they'd fail, but...well...one never DOES know, does one? My guess is the "huge" moniker is the trouble.

(And before you ask, yes, vim is a dependency of mpv it seems maybe? But it also wants to install a version of bash, so who knows...maybe just cascading dependencies...)

 

[barracuda156]

Ha...vim 404 not found:
---> Fetching archive for vim
---> vim-9.1.1324_0+huge.darwin_8.ppc.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified
---> Attempting to fetch vim-9.1.1324_0+huge.darwin_8.ppc.tbz2 from http://macos-powerpc.org/packages/vim
...
mirrors all around the world then fail too
...
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0Error: Failed to fetch vim: The requested URL returned error: 404
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_macos-powerpc.org_macos-powerpc_PPCPorts_ports_editors_vim/vim/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

Tried multiple times, and even just installing vim by itself...I knew they'd fail, but...well...one never DOES know, does one? My guess is the "huge" moniker is the trouble.

(And before you ask, yes, vim is a dependency of mpv it seems maybe? But it also wants to install a version of bash, so who knows...maybe just cascading dependencies...)

Obviously, we do not [yet] have anything pre-built for 10.4, so that is not found. I think downloading the source fails due to GitHub requiring now modern curl, while you have built PPCPorts without it. MacPorts distfiles do not have it, because I have a newer version of vim in its portfile.

There can be a few solutions:
1. Manually fetch the source for needed version of vim from its upstream and place it inside /opt/local/var/macports/distfiles/vim.
2. Modify vim portfile to use the same version which MacPorts has, so that the tarball can be downloaded from MacPorts distfiles.
3. Build PPCPorts against external curl. Or against its own curl (not recommended, but doable).

Option #3 is the only long-term solution, otherwise you will need to go through hacking every time MacPorts do not have a source tarball of needed version.
You can build external curl like this. Configure and install ports in /opt/bootstrap (for example):

export PATH=/usr/bin:/usr/sbin:/bin:/sbin
cd macports-base
./configure --prefix=/opt/bootstrap --with-applications-dir=/opt/bootstrap/Applications --without-startupitems
make
sudo make install

Then:

export PATH=/opt/bootstrap/bin:/opt/bootstrap/sbin:/usr/bin:/usr/sbin:/bin:/sbin
cd /opt/bootstrap
sudo ./port -v sync
sudo ./port -v -N install curl -brotli

(Without brotli just to save time, so that cmake-bootstrap is not needed.)
Once that is installed, rebuild the main base as:

export PATH=/usr/bin:/usr/sbin:/bin:/sbin
cd macports-base
./configure --with-curlprefix=/opt/bootstrap
make
sudo make install

See also: https://github.com/macos-powerpc/ma...d7cf0dd20fc3ca5ab496564/configure#L1512-L1552

 

[lauland]

Obviously, we do not [yet] have anything pre-built for 10.4, so that is not found. I think downloading the source fails due to GitHub requiring now modern curl, while you have built PPCPorts without it. MacPorts distfiles do not have it, because I have a newer version of vim in its portfile.

There can be a few solutions:
1. Manually fetch the source for needed version of vim from its upstream and place it inside /opt/local/var/macports/distfiles/vim.
2. Modify vim portfile to use the same version which MacPorts has, so that the tarball can be downloaded from MacPorts distfiles.
3. Build PPCPorts against external curl. Or against its own curl (not recommended, but doable).

Option #3 is the only long-term solution, otherwise you will need to go through hacking every time MacPorts do not have a source tarball of needed version.
You can build external curl like this. Configure and install ports in /opt/bootstrap (for example):

export PATH=/usr/bin:/usr/sbin:/bin:/sbin
cd macports-base
./configure --prefix=/opt/bootstrap --with-applications-dir=/opt/bootstrap/Applications --without-startupitems
make
sudo make install

Then:

export PATH=/opt/bootstrap/bin:/opt/bootstrap/sbin:/usr/bin:/usr/sbin:/bin:/sbin
cd /opt/bootstrap
sudo ./port -v sync
sudo ./port -v -N install curl -brotli

(Without brotli just to save time, so that cmake-bootstrap is not needed.)
Once that is installed, rebuild the main base as:

export PATH=/usr/bin:/usr/sbin:/bin:/sbin
cd macports-base
./configure --with-curlprefix=/opt/bootstrap
make
sudo make install

See also: https://github.com/macos-powerpc/ma...d7cf0dd20fc3ca5ab496564/configure#L1512-L1552

Ok...you know what you're talking about, with macports, and I most definitely do not. So, you'd go with option #3, but don't recommend it...necessarily?

From what you know about my skill level, but, far more importantly, what would be most useful to YOU, do you think I should do next? I'm only doing this just to get mpv to look at it and maybe poke around in SDL2 to get it working better for you (and everyone), so whatever would serve that best is fine with me. I don't mind trying things.

FYI I'm still going to work on the SDL2 Cocoa video driver (and maybe joystick and coreaudio also) for Tiger vintage OS's (using recent SDL2, not 2.0.3), but that's a separate project, and macports isn't necessarily needed for it. I'm just into SDL2 on all platforms. Actually worked on it for m68k amiga this week. I can probably look at SDL3 at some point also, but have been focusing on SDL2, so it's outside my current scope.

 

[lauland]

Hmm...I decided while the machine was sitting idle, I might as well try installing some of the other mpv dependencies. Looks like most of them want gcc14, and there are problems with libgcc14.

It tells me I need to deactivate libunwind-headers, but after doing so, when trying to configure, it tries to use /opt/local/libexec/gcc10-bootstrap/bin/gcc -arch ppc, and that "cannot create executables". I'm looking into it.

nameserver:/opt/local/libexec/gcc10-bootstrap/bin lauland$ ./gcc ~/hello.c
dyld: Library not loaded: /usr/local/lib/libisl.15.dylib
Referenced from: /opt/local/libexec/gcc10-bootstrap/libexec/gcc/powerpc-apple-darwin8/10.5.0/cc1
Reason: image not found
gcc: internal compiler error: Trace/BPT trap signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://trac.macports.org/newticket> for instructions.

That lib doesn't exist, missing depenedency maybe? Trying installing isl-devel again...could be me being stupid with TigerBrew when I built the bootstrap compilers...so...maybe ignore me on this one until after I've rebuilt them.

(Of course if I had TigerBrew active while building ANYTHING my whole ports install may be cattywampus, OMG, linked to libs that were in it, sorry...rebuilding everything now...well...at least I know I didn't cause the vim problem! I really should have known better...)

 

[barracuda156]

Ok...you know what you're talking about, with macports, and I most definitely do not. So, you'd go with option #3, but don't recommend it...necessarily?

From what you know about my skill level, but, far more importantly, what would be most useful to YOU, do you think I should do next? I'm only doing this just to get mpv to look at it and maybe poke around in SDL2 to get it working better for you (and everyone), so whatever would serve that best is fine with me. I don't mind trying things.

FYI I'm still going to work on the SDL2 Cocoa video driver (and maybe joystick and coreaudio also) for Tiger vintage OS's (using recent SDL2, not 2.0.3), but that's a separate project, and macports isn't necessarily needed for it. I'm just into SDL2 on all platforms. Actually worked on it for m68k amiga this week. I can probably look at SDL3 at some point also, but have been focusing on SDL2, so it's outside my current scope.

I guess my phrasing was confusing, sorry. What I meant is that the recommended way is to have a separate tree just for curl and (re)build main installation against that. This is how I set it up myself, and how it is set up via prebuilt installers for 10.6.
It is also possible to rebuild the base against itself once curl is installed, i.e. use `--with-curlprefix=/opt/local`. This is not recommended, because it is fragile: say, you deactivate curl port, and MacPorts cannot work until it is reactivated. But this way saves time. I think you can go with this, it does not hurt (i.e. you can always rebuild the base without rebuilding ports, it is quick).

 

[barracuda156]

Hmm...I decided while the machine was sitting idle, I might as well try installing some of the other mpv dependencies. Looks like most of them want gcc14, and there are problems with libgcc14.

It tells me I need to deactivate libunwind-headers, but after doing so, when trying to configure, it tries to use /opt/local/libexec/gcc10-bootstrap/bin/gcc -arch ppc, and that "cannot create executables". I'm looking into it.

Yes, `libunwind-headers` should not be active when building (lib)gcc and a few other ports, that is correct. It is used for cctools, I think, so it will be installed, and you need to deactivate it manually before building gcc.

I do not know what is wrong with gcc10-bootstrap. Log will be helpful. Also you could try compiling a single C file with it, to make sure it works.

 

[barracuda156]

P. S. Please update me on gcc10-bootstrap, let’s sort it out. For curl, if it is problematic to do locally, I can find time to build the installer in coming days. Let me know if needed.

 

[lauland]

P. S. Please update me on gcc10-bootstrap, let’s sort it out. For curl, if it is problematic to do locally, I can find time to build the installer in coming days. Let me know if needed.

Ok, before I proceed any further, I believe rebuilding my /opt/local is probably prudent. This is because as I mentioned above, I may have had TigerBrew active in /usr/local, at least part of the part of my journey so far.

I'm not positive if I did or not, I at least DID know there would very likely be conflicts: When a port configures, and looks for headers and libs, it may find ones installed from TigerBrew packages. I know the order of $PATH is very simple to determine which binaries take priority, but headers and libs are less predictable. I definitely had libisl there, so it is very likely that is the problem with bootstrap-gcc.

I'm making a backup, and will compare afterwards as a post mortum to see if that was the case or not, but regardless, it is prudent.

We'll revisit the vim/curl issue on the other side.

PS Should we break this out into a separate "Tiger PowerPC Ports" topic, this has gotten off subject of SDL2, and I'd kind of like to get back to that. I at least feel in my element there.

 

[barracuda156]

Ok, before I proceed any further, I believe rebuilding my /opt/local is probably prudent. This is because as I mentioned above, I may have had TigerBrew active in /usr/local, at least part of the part of my journey so far.

I'm not positive if I did or not, I at least DID know there would very likely be conflicts: When a port configures, and looks for headers and libs, it may find ones installed from TigerBrew packages. I know the order of $PATH is very simple to determine which binaries take priority, but headers and libs are less predictable. I definitely had libisl there, so it is very likely that is the problem with bootstrap-gcc.

I'm making a backup, and will compare afterwards as a post mortum to see if that was the case or not, but regardless, it is prudent.

We'll revisit the vim/curl issue on the other side.

PS Should we break this out into a separate "Tiger PowerPC Ports" topic, this has gotten off subject of SDL2, and I'd kind of like to get back to that. I at least feel in my element there.

You can just backup /opt/local/var/macports/software folder. Those are pre-built ports.
I agree, it makes sense to do builds in a clean environment, and perhaps indeed better restart early, if there is a high chance of incorrect linking and header usage.
(It is easy to detect wrong linking – once you delete or move away Homebrew libs, ports will be detected as broken, if they linked to a now missing library. However, there is no way to detect if incorrect headers were used during a build.)

 

[lauland]

I've been at a conference all week, but am finally back to work on this again.

Starting over from scratch, this time being sure there was no TigerBrew in /usr/local, it still did the strange failure on legacy-support, but, again, worked fine when I installed just it. Weird, but easily gotten around.

Since gcc14 is a dependency on a lot of the mpv dependencies, and where I got stuck last time, I'm skipping to the chase and installing just it now. It'll build at least one of the bootstrap gcc's in order to build that, so the g4 is rumbling again. Building those two compilers will probably take at least a day (or two). It's highly likely TigerBrew's fault that gcc14 failed last time, so I expect to get past that point this time.

 

[barracuda156]

I've been at a conference all week, but am finally back to work on this again.

Starting over from scratch, this time being sure there was no TigerBrew in /usr/local, it still did the strange failure on legacy-support, but, again, worked fine when I installed just it. Weird, but easily gotten around.

Since gcc14 is a dependency on a lot of the mpv dependencies, and where I got stuck last time, I'm skipping to the chase and installing just it now. It'll build at least one of the bootstrap gcc's in order to build that, so the g4 is rumbling again. Building those two compilers will probably take at least a day (or two). It's highly likely TigerBrew's fault that gcc14 failed last time, so I expect to get past that point this time.

I really got no idea myself about the state of the toolchain on Tiger, but apparently at least two people have successfully built gcc14 very recently, and after that no breaking changes should have occurred.

P. S. Typing this in, I remembered one thing which could at least differ. Could you say if `isl-devel`installed earlier or not, or does it install? I am not sure it was tested by someone on Tiger. It is perhaps safer to use an older `isl` instead (it is fine, MacPorts still uses it on all systems by default).
I can actually push a Tiger-specific change for this.

 

[barracuda156]

I've been at a conference all week, but am finally back to work on this again.

Starting over from scratch, this time being sure there was no TigerBrew in /usr/local, it still did the strange failure on legacy-support, but, again, worked fine when I installed just it. Weird, but easily gotten around.

Since gcc14 is a dependency on a lot of the mpv dependencies, and where I got stuck last time, I'm skipping to the chase and installing just it now. It'll build at least one of the bootstrap gcc's in order to build that, so the g4 is rumbling again. Building those two compilers will probably take at least a day (or two). It's highly likely TigerBrew's fault that gcc14 failed last time, so I expect to get past that point this time.

On a second thought, I rather wait for @cellularmitosis to confirm if he has built gcc14 or not on Tiger. If he did, then we keep `isl-devel`. I do not want to force someone rebuild gcc14 accidentally.

For now, it is probably safer to go with a non-devel version of `isl`. You do not even need to edit gcc14 portfile for that, it will be enough to install `isl` explicitly first, before installing libgcc14.

sudo port deactivate isl-devel
sudo port -v install isl
. . .

(If you already have compiled libgcc14 with `isl-devel`, nothing to worry about, all is good.)

 

[barracuda156]

P. S. Just to provide some clarity on `isl` thing, this line in the portfile has an effect of picking `isl-devel` by default, but allows `isl` to satisfy the dependency as well: https://github.com/macos-powerpc/po...b707b0d1bd641ff7d353e/lang/gcc14/Portfile#L61
MacPorts has the reverse setting (allows isl-devel, but picks isl by default).

While gcc can be built against different versions of isl (not just these two), it will need to keep using the same version which it was built against. So if someone already has built gcc14 with isl-devel on Tiger, and I change the default choice to a non-devel isl port, that creates a problem if that user deactivates installed ports and then tries to build something which needs gcc14 (since default is changed, it will activate a wrong isl library, and compiler will not work).

It is of course fine to try using `isl-devel` first and only switch to `isl` if the first option fails, but that may waste some time on recompiling.

 

[lauland]

Absolutely wait until making ANY changes until you confirm with @cellularmitosis AND wait for my poor extremely overworked G4 gets that far. It is still building one of the bootstrap compilers, and probably won't get to gcc14 until sometime this weekend.

I definitely had a version of isl installed via TigerBrew when I ran into that problem, previously. It is very highly likely the port build's configure found that and used it building one of gcc14's depenedencies (namely one of the bootstrap gcc's).

When I then noticed I still had TigerBrew, prior to trying building gcc14, and suddenly (somewhat hastily) disabled TigerBrew, the bootstrap compiler broke. Yes, I COULD have reenabled TigerBrew and probably gotten it working, but I would've had a VERY mutant system which wouldn't have helped either me, or you in shaking out Tiger bugs...my system wouldn't resemble pretty much anyone else's!

So, chances are very good that this time it will work. At least if it DOES work at all on Tiger, it will work for me.

We'll just have to give it a little time...

 

[lauland]

Absolutely wait until making ANY changes until you confirm with @cellularmitosis AND wait for my poor extremely overworked G4 gets that far. It is still building one of the bootstrap compilers, and probably won't get to gcc14 until sometime this weekend.

I definitely had a version of isl installed via TigerBrew when I ran into that problem, previously. It is very highly likely the port build's configure found that and used it building one of gcc14's depenedencies (namely one of the bootstrap gcc's).

When I then noticed I still had TigerBrew, prior to trying building gcc14, and suddenly (somewhat hastily) disabled TigerBrew, the bootstrap compiler broke. Yes, I COULD have reenabled TigerBrew and probably gotten it working, but I would've had a VERY mutant system which wouldn't have helped either me, or you in shaking out Tiger bugs...my system wouldn't resemble pretty much anyone else's!

So, chances are very good that this time it will work. At least if it DOES work at all on Tiger, it will work for me.

We'll just have to give it a little time...

I'm at the point where libgcc14 fails because libunwind-headers is installed. The helpful error message tells me I can deactivate them to build libgcc14, and reactivate them later if I wish. So I'm building libgcc14 as we speak.

(Building dependencies to get to this point was unexpectedly delayed when cats trod upon keyboard and stopped a build).

It's unclear if I should reactivate libunwind-headers, and, if I do, when (before or after I attempt building gcc14 itself). I can find a couple mentions of the conflict, including one about building on PPC Leopard:

#71665 (libgcc14 @14.2.0_1 does not build on PPC Leopard, Mac OS X 10.5.8, because of ld: bl PPC branch out of range) – MacPorts

trac.macports.org

But it doesn't mention that they actually deactivated them...I'm assuming they did since they eventually got gcc14 built...nor does it mention if they bothered reactivating them later.

For now, I'm just going to assume that if something else I build requires them, it'll notice they aren't active, and tell me...

 

[barracuda156]

I'm at the point where libgcc14 fails because libunwind-headers is installed. The helpful error message tells me I can deactivate them to build libgcc14, and reactivate them later if I wish. So I'm building libgcc14 as we speak.

(Building dependencies to get to this point was unexpectedly delayed when cats trod upon keyboard and stopped a build).

It's unclear if I should reactivate libunwind-headers, and, if I do, when (before or after I attempt building gcc14 itself). I can find a couple mentions of the conflict, including one about building on PPC Leopard:

#71665 (libgcc14 @14.2.0_1 does not build on PPC Leopard, Mac OS X 10.5.8, because of ld: bl PPC branch out of range) – MacPorts

trac.macports.org

But it doesn't mention that they actually deactivated them...I'm assuming they did since they eventually got gcc14 built...nor does it mention if they bothered reactivating them later.

For now, I'm just going to assume that if something else I build requires them, it'll notice they aren't active, and tell me...

No, you do not need `libunwind-headers` for anything at all, I believe, aside of building cctools. In any case they will be automatically activated if something happens to need them. So just deactivate them and leave at that.

Generally, it should not be needed to activate or install anything not directly wanted (as long as you go with defaults). All dependencies should be handled by ports. It is always safer to have everything unnecessary deactivated, especially if you build something important or just time-consuming. So that you don’t end up needing to rebuild that due to opportunistic linking to something.

It will probably be too annoying to deactivate all ports before building every next port, but at least do that for the toolchain.
I normally run `sudo port deactivate active` prior to building stuff (not literally everything, but largely).

 

[lauland]

No, you do not need `libunwind-headers` for anything at all, I believe, aside of building cctools. In any case they will be automatically activated if something happens to need them. So just deactivate them and leave at that.

Generally, it should not be needed to activate or install anything not directly wanted (as long as you go with defaults). All dependencies should be handled by ports. It is always safer to have everything unnecessary deactivated, especially if you build something important or just time-consuming. So that you don’t end up needing to rebuild that due to opportunistic linking to something.

It will probably be too annoying to deactivate all ports before building every next port, but at least do that for the toolchain.
I normally run `sudo port deactivate active` prior to building stuff (not literally everything, but largely).

gcc14 finally finished successfully, so my guess about TigerBrew being the problem before was correct. So, yes, it is definitely possible on Tiger PPC. Tested with hello worlds.

On to more mpv dependencies...probably all the x11 would be good to do next

But first, I believe a side quest about Cocoa for SDL2 beckons.

 

[barracuda156]

gcc14 finally finished successfully, so my guess about TigerBrew being the problem before was correct. So, yes, it is definitely possible on Tiger PPC.

Could you check which `isl` is used? Assuming you did not deactivate gcc14, you can check like this:

port -v installed | grep isl

 

[lauland]

nameserver:~ lauland$ port -v installed | grep isl
isl-devel @0.27_0 (active) requested_variants='' platform='darwin 8' archs='ppc' date='2025-05-23T23:23:14-0500'

FYI It looks like my SDL2 builds WERE dependent on something via TigerBrew (this is totally unrelated to the gcc14 stuff). I tried building the two different versions on the G4 and got odd results. Did the same on a mini that still has TigerBrew and no MacPorts and they're fine. Not sure what is going on, but will figure it out.

So I'm keeping them separate for now. SDL2 on the mini, macports on the g4.

 

[barracuda156]

But first, I believe a side quest about Cocoa for SDL2 beckons.

Provided mpv will be able to use SDL2 Cocoa, while not being build as Cocoa app itself, that can be a huge improvement.

I did some testing with heavy video playback recently in relation to QMPlay2, and while everything evidently fell behind it, mpv in its latest version was not too bad, and if it will avoid relying on X11, it can possibly more or less match QMPlay2 or even surpass it with some types of vids.

 

[lauland]

So, I have the Cocoa driver building with SDL 2.32.4 now, but it crashes. It is probably trying to make a few calls that are legal to the compiler, but fail at runtime when done dynamically.

I fixed the obvious errors, some just due to how SDL2 had changed through the years, but left the warnings about "may not respond to" etc alone. Going to circle back and look at each of them. May just be able to comment them out if they aren't strictly necessary for basic functionality. It MIGHT work...

UPDATE: Yes, it seems to work, even opengl.

 

[barracuda156]

So, I have the Cocoa driver building with SDL 2.32.4 now, but it crashes. It is probably trying to make a few calls that are legal to the compiler, but fail at runtime when done dynamically.

I fixed the obvious errors, some just due to how SDL2 had changed through the years, but left the warnings about "may not respond to" etc alone. Going to circle back and look at each of them. May just be able to comment them out if they aren't strictly necessary for basic functionality. It MIGHT work...

UPDATE: Yes, it seems to work, even opengl.

This is fantastic!

Please make a tree, I would like to try that out.