SDL2 for older MacOS X

[barracuda156]

Done, and, perhaps throwing caution to the wind, did selfupdate.

Looks good so far, will try something really crazy like "sudo port install mpv" soon, and let you know what happens.

You may need these two, though if darwin-xtools work, then just try using them.

cctools: change defaults for 10.4 ppc to match upstream · macos-powerpc/powerpc-ports@ccbf14e

Overlay repo with fixes to use with MacPorts on macOS PowerPC - cctools: change defaults for 10.4 ppc to match upstream · macos-powerpc/powerpc-ports@ccbf14e

github.com

ld64: change defaults for 10.4 ppc to match upstream · macos-powerpc/powerpc-ports@2d8ac46

Tiger is a pain to build anything. Just use what has already been tested and confirmed to work. We do not know atm if darwin-xtools or llvm-powerpc work on 10.4.

github.com

Update. I have uploaded a new ports tarball, so running `port sync` will update ld64 and cctools ports.

 

[barracuda156]

@lauland Once you confirm it actually works on 10.4 (the base I mean), I will pick commit restoring support into the master and update MacPorts port in sysutils accordingly.

 

[lauland]

Installing now...348 packages...

 

[barracuda156]

Installing now...348 packages...

If it gets to building gcc14, consider all is good. (If it starts pulling in llvm stuff automatically, something is not right, and variants logic should be reviewed.)
Compiler itself didn’t change much, so that should work.

What hardware have you got btw? gcc14 takes a lot of time, be prepared.

 

[lauland]

If it gets to building gcc14, consider all is good. (If it starts pulling in llvm stuff automatically, something is not right, and variants logic should be reviewed.)
Compiler itself didn’t change much, so that should work.

What hardware have you got btw? gcc14 takes a lot of time, be prepared.

gcc14 is listed among what it will be building, llvm is not, so good sign maybe...

It is a dual 1.6ghz g4 with 2g of ram, and I well understand how long it will take from building gcc's in the past. So...see you in a day or two?

 

[barracuda156]

gcc14 is listed among what it will be building, llvm is not, so good sign maybe...

It is a dual 1.6ghz g4 with 2g of ram, and I well understand how long it will take from building gcc's in the past. So...see you in a day or two?

Dual 1.6 G4? Is that some Sonnet upgrade?

Yeah, one gcc14 build will probably take ~15+ hrs, there are two needed, and 2 or 3 gcc on the way. But for a desktop no issues.

On dual 2.3 one build took about 12 hrs last time I built gcc14.

 

[lauland]

It's a "newertek maxpower" thingie. I bought the machine used and it came with it. But yes, fully expect to take a day or two or even three...or four? To build everything...

Ah...it just failed building "legacy_support". (Was doing "sudo port install mpv")

Trying again, just THAT package and it seems to be doing things...libmacho...xz-bootstrap...

If it fails again, I'll look at the logs, keep trying things, etc, until I get stuck and will then get you the failure log.

 

[barracuda156]

It's a "newertek maxpower" thingie. I bought the machine used and it came with it. But yes, fully expect to take a day or two or even three...or four? To build everything...

Ah...it just failed building "legacy_support". (Was doing "sudo port install mpv")

Trying again, just THAT package and it seems to be doing things...libmacho...xz-bootstrap...

If it fails again, I'll look at the logs, keep trying things, etc, until I get stuck and will then get you the failure log.

This is surprising if `legacy-support` fails (and rather ironic). I think it is supposed to support 10.4 officially still, and tickets can be opened (make sure to choose legacy-support as a category).
It should not be a big deal to use an older version of it for the time-being, as a temporary solution. Most of needed functionality exists there for years, and latest additions are nothing crucial.

Worth checking if someone decided to dump 10.4-specific code from the portfile. If that is the case, we can restore it.
But it is preferable to deal with upstream on this specific matter, if the port indeed no longer builds.

 

[lauland]

This is surprising if `legacy-support` fails (and rather ironic). I think it is supposed to support 10.4 officially still, and tickets can be opened (make sure to choose legacy-support as a category).
It should not be a big deal to use an older version of it for the time-being, as a temporary solution. Most of needed functionality exists there for years, and latest additions are nothing crucial.

Worth checking if someone decided to dump 10.4-specific code from the portfile. If that is the case, we can restore it.
But it is preferable to deal with upstream on this specific matter, if the port indeed no longer builds.

legacy-support installed fine when I did it separately individually. Trying mpv again.

As I said, if I run into any problems I'll try workarounds until I get stuck.

 

[barracuda156]

While this should not be a requirement, I generally prefer to define a sequence (as long as the aim is not to test for robustness of reproducible builds but just to build the stuff). Say, gcc – cmake – user-end port. So that nothing unnecessary for building toolchain is pulled in due to no dependencies and alphabetic sorting.

 

[lauland]

It seems to be going well so far...it is chewing on gcc7-bootstrap, but has already built tons of smaller things before that.

So far this is what I did:
sudo port install mpv

It errored on legacy-support, so:
sudo port intsall legacy-support

Which went fine, so now again:
sudo port install mpv

 

[barracuda156]

Sounds good.

We should see later if legacy-support build error is deterministic. (While everyone should expect that some ports won’t build, and that is the case in upstream MacPorts as well, and perhaps everywhere, it is desirable to have a reproducible and robust process of getting from Xcode to a minimal, but fully-functional toolchain. So at least a few dependencies for that should build 100% of time.)

 

[lauland]

I have another tiger machine I can try an install on and see if it also has trouble with legacy-support.

Will let you know.

 

[lauland]

Well, after a day or two of building, including multiple gcc's, it failed on m4, of all things. I'll get you the log file after I've determined if I can get past it myself or not.

 

[barracuda156]

Well, after a day or two of building, including multiple gcc's, it failed on m4, of all things. I'll get you the log file after I've determined if I can get past it myself or not.

I guess no one tried to build the latest version on Tiger. Update was a week ago:

m4: update to 1.4.20 · macports/macports-ports@a945390

https://lists.gnu.org/archive/html/m4-announce/2025-05/msg00000.html The removed patch has been incorporated into the bundled gnulib. I don't know if any of our other changes are also unnecess...

github.com

and https://github.com/macos-powerpc/powerpc-ports/commit/5187ad65c4e412fc914dbb33a7cb9997b900b2ce
I will check now if the patch still applies. If it does, then you may need to fix w/e fails or revert to the previous version. (I can push the revert for 10.4, but please make sure it works first.)

 

[barracuda156]

Well, after a day or two of building, including multiple gcc's, it failed on m4, of all things. I'll get you the log file after I've determined if I can get past it myself or not.

Update. Well, it may not be broken. Just the patch does not apply. LOL.
(Well, in this case both MacPorts and myself declared a lack of support for Tiger, so this was sorta expected.)

Update2. It is yet funnier. Apparently upstream tried to fix the issue for Tiger ppc, which is why the patch does not apply. However, it uses Linux macro – unless it is somewhere defined for macOS too – this code will never be used:

# elif defined __powerpc__

/* See the definitions of
     - 'ucontext_t' and 'struct __darwin_ucontext' in <sys/_structs.h>,
     - 'struct __darwin_mcontext' in <ppc/_structs.h>, and
     - 'struct __darwin_ppc_thread_state' in <mach/ppc/_structs.h>.  */
#  if !(defined _STRUCT_MCONTEXT || defined _STRUCT_MCONTEXT32 || defined _STRUCT_MCONTEXT64)
/* Mac OS X 10.4 and earlier omitted the underscores.  */
#   define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *) ucp)->uc_mcontext->ss.r1
#  else
#   define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *) ucp)->uc_mcontext->__ss.__r1
#  endif

Anyway, I will fix the macro now and remove unneeded part of the patch. Gimme a few min.

Update. Hope this works for you: https://github.com/macos-powerpc/powerpc-ports/commit/8d5e764f92a3b51c0f8fbf62b84d8fcd9e8adefa
I will update ports tarball now.

 

[lauland]

Update. Well, it may not be broken. Just the patch does not apply. LOL.
(Well, in this case both MacPorts and myself declared a lack of support for Tiger, so this was sorta expected.)

Update2. It is yet funnier. Apparently upstream tried to fix the issue for Tiger ppc, which is why the patch does not apply. However, it uses Linux macro – unless it is somewhere defined for macOS too – this code will never be used:

# elif defined __powerpc__

/* See the definitions of
     - 'ucontext_t' and 'struct __darwin_ucontext' in <sys/_structs.h>,
     - 'struct __darwin_mcontext' in <ppc/_structs.h>, and
     - 'struct __darwin_ppc_thread_state' in <mach/ppc/_structs.h>.  */
#  if !(defined _STRUCT_MCONTEXT || defined _STRUCT_MCONTEXT32 || defined _STRUCT_MCONTEXT64)
/* Mac OS X 10.4 and earlier omitted the underscores.  */
#   define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *) ucp)->uc_mcontext->ss.r1
#  else
#   define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *) ucp)->uc_mcontext->__ss.__r1
#  endif

Anyway, I will fix the macro now and remove unneeded part of the patch. Gimme a few min.

Update. Hope this works for you: https://github.com/macos-powerpc/powerpc-ports/commit/8d5e764f92a3b51c0f8fbf62b84d8fcd9e8adefa
I will update ports tarball now.

Hm...makes you wonder if they ever actually bother to build some of their fixes, eh...at least not on Tiger ppc...but who would be crazy enough to try using such a machine? Amusing...

If you updated the ports tarball, it sounds like just re-running MIGHT now work, right? I'm doing selfupdate to get updated ports, and will try that after it finishes now.

If it doesn't I'll try the patch. I don't think I've ever patched a port by hand and then been able to build it, but if I do need to, it will be a good thing to learn how to do.

Here goes...

 

[barracuda156]

Hm...makes you wonder if they ever actually bother to build some of their fixes, eh...at least not on Tiger ppc...but who would be crazy enough to try using such a machine? Amusing...

If you updated the ports tarball, it sounds like just re-running MIGHT now work, right? I'm doing selfupdate to get updated ports, and will try that after it finishes now.

If it doesn't I'll try the patch. I don't think I've ever patched a port by hand and then been able to build it, but if I do need to, it will be a good thing to learn how to do.

Here goes...

i re-run `port sync` several times per-day, on a G5 it is tolerable. For development I recommend doing the same, that at least ensures that our fixes land with no delay.

P. S. No, MacPorts folks casually ignore verifying and rebasing patches. For example, this patch is unneeded, since I fixed the issue with upstream, and it doesn’t apply now; not only it sits in portfile at least through two versions, leaving them broken, but I explicitly informed about this issue 4 month ago – guess what, nothing was done ever since. Despite the only “fix” required is to trash the patch. This is not a cherry-picked, unique example. This PR since April is marked as WIP, and once merged, `abseil` won’t build – again, the only reason for that being a failure to rebase the patch (literally a part of it simply has to be deleted, that’s it). This commit deleted the patch for `snappy` which left its dependents broken for all archs; it was restored after I explaned the situation. So it is absolutely systemic and should be expected. If a patch is conditional, likely it will never be verified, if it is not conditional, it can be dropped, once it does not apply cleanly, regardless of whether it is needed or not, including for modern macOS.

I recommend building anything with `-v` always, and if anything fails, first thing to make sure is whether MacPorts has broken the port – whether by patch-related issue or by adding an arch-specific hack unconditionally. A lot of python ports are broken for no reason – just because `libomp` dependency is added unconditionally, while is must be used only with clang. Here is a recent example. Several times I have wasted time searching though source code for some silly flag which broken the build – only to find out it was added in the portfile. Etc.

 

[lauland]

i re-run `port sync` several times per-day, on a G5 it is tolerable. For development I recommend doing the same, that at least ensures that our fixes land with no delay.

P. S. No, MacPorts folks casually ignore verifying and rebasing patches. For example, this patch is unneeded, since I fixed the issue with upstream, and it doesn’t apply now; not only it sits in portfile at least through two versions, leaving them broken, but I explicitly informed about this issue 4 month ago – guess what, nothing was done ever since. Despite the only “fix” required is to trash the patch. This is not a cherry-picked, unique example. This PR since April is marked as WIP, and once merged, `abseil` won’t build – again, the only reason for that being a failure to rebase the patch (literally a part of it simply has to be deleted, that’s it). This commit deleted the patch for `snappy` which left its dependents broken for all archs; it was restored after I explaned the situation. So it is absolutely systemic and should be expected. If a patch is conditional, likely it will never be verified, if it is not conditional, it can be dropped, once it does not apply cleanly, regardless of whether it is needed or not, including for modern macOS.

I recommend building anything with `-v` always, and if anything fails, first thing to make sure is whether MacPorts has broken the port – whether by patch-related issue or by adding an arch-specific hack unconditionally. A lot of python ports are broken for no reason – just because `libomp` dependency is added unconditionally, while is must be used only with clang. Here is a recent example. Several times I have wasted time searching though source code for some silly flag which broken the build – only to find out it was added in the portfile. Etc.

Yeah, you confirmed my fears regarding the MacPorts folk. But I half understand, I'm glad it's not ME having to maintain something like that.

So it just now failed building lame. I'm too tired to bother looking further right now...will let you know what I find later.

 

[lauland]

Yeah, you confirmed my fears regarding the MacPorts folk. But I half understand, I'm glad it's not ME having to maintain something like that.

So it just now failed building lame. I'm too tired to bother looking further right now...will let you know what I find later.

build lame failing: Ah, the irony. Problems in LegacySupport.

Line 139 in sdkversion.h in /opt/local/include/LegacySupport/_macports_extras checks MAC_OS_X_VERSION_MAX_ALLOWED < 1040, not entirely sure why this failed, but /usr/include/AvailabilityMacros.h must be setting it lower. Commenting out the line helps...but. then...

Several of the .h files in LegacySupport use #include_next <SOMETHING.h> so like its stdlib.h wants to pull in the real stdlib.h that way...but this is failing. Because all those files actually exist in /usr/include, but the build throws an error, I'm thinking maybe compiler problem?

It is using /opt/local/bin/gcc-apple-4.2. I thought it built a newer gcc as one of the mpv dependencies, but I don't see any others in /opt/local. So, I'm thinking I could use port to install a newer gcc, and then tell the port command to use that to build lame, or I can use gcc-8.5, which I already have on my drive through TigerBrew.

I don't know how to tell port to use a different gcc, but I'm going to see if I can figure it out.

 

[lauland]

Using the gcc-8.5 from TigerBrew didn't work, but maybe got a little farther...it kept having trouble finding include files. It looked like port was passing the right include locations and using sysroot, but still couldn't find things. Looks like the way the build is set up, it doesn't use /usr/include at all actually, but probably the 10.4 SDK instead?

Regardless, stuck at building lame...so...lame!

 

[barracuda156]

Using the gcc-8.5 from TigerBrew didn't work, but maybe got a little farther...it kept having trouble finding include files. It looked like port was passing the right include locations and using sysroot, but still couldn't find things. Looks like the way the build is set up, it doesn't use /usr/include at all actually, but probably the 10.4 SDK instead?

Regardless, stuck at building lame...so...lame!

Could you post the log from the default build? I will look into that today. It certainly builds on a G5 on 10.6.
I have probably broken lame for G3 earlier and forgot to address the issue, but that should not affect you.
If I have needed deps on my old 10.4, I can try reproducing it.

 

[barracuda156]

Using the gcc-8.5 from TigerBrew didn't work, but maybe got a little farther...it kept having trouble finding include files. It looked like port was passing the right include locations and using sysroot, but still couldn't find things. Looks like the way the build is set up, it doesn't use /usr/include at all actually, but probably the 10.4 SDK instead?

Regardless, stuck at building lame...so...lame!

It is preferable to avoid any external compilers besides Apple Xcode ones. Not because there is anything wrong with them, but it makes a build non-reproducible and impossible to debug. So even if it works for you locally, the problem gonna stay for everyone else.

If there is any reason to have some additional compiler which MacPorts does not have, or add patches from Homebrew into some gcc, we can do that.

 

[lauland]

It is preferable to avoid any external compilers besides Apple Xcode ones. Not because there is anything wrong with them, but it makes a build non-reproducible and impossible to debug. So even if it works for you locally, the problem gonna stay for everyone else.

If there is any reason to have some additional compiler which MacPorts does not have, or add patches from Homebrew into some gcc, we can do that.

Naw, the only idea was I wanted to try everything I could, to see if I could narrow down the problem. Maybe something as simple as "lame doesn't build with gcc-apple-4.2". I looked at gcc ports, but decided to wait until I heard back from you, and I just had gcc-8.5 handy. Regardless, it didn't work.

I'll get you the log soon.

 

[barracuda156]

Naw, the only idea was I wanted to try everything I could, to see if I could narrow down the problem. Maybe something as simple as "lame doesn't build with gcc-apple-4.2". I looked at gcc ports, but decided to wait until I heard back from you, and I just had gcc-8.5 handy. Regardless, it didn't work.

I'll get you the log soon.

BTW, you could also try this:

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