Notes on Godot 3.3.2 and legacy OS's.

[Wowfunhappy (Jonathan)]

As of this writing, MacPorts's Godot port is still on version 3.2.3. The latest upstream version, 3.3.2, has officially dropped support for OS's older than 10.12, but it can still work at least as far back as 10.9 with some tweaks, and with the help of macports-libcxx.

I wanted to document what I'd discovered for future users.

---

1.

In the Portfile, the line:

reinplace s|${sconstruct_default_mp_clang}\.0|${selected_clang_v}|g \
    ${worksrcpath}/SConstruct

needs to be replaced with

reinplace s|${sconstruct_default_mp_clang}\.0|${selected_clang_v}|g \
    ${worksrcpath}/platform/osx/detect.py

Because SConstruct was factored out into separate, per-platform files.

---

2.

For a reason I wasn't able to track down, the lines:

#if MAC_OS_X_VERSION_MAX_ALLOWED < 101200
#if MAC_OS_X_VERSION_MAX_ALLOWED >= 101200

in platform/osx/os_osx.mm no longer have the desired effect; the compiler is convinced MAX_ALLOWED is always above 101200. I had to manually comment out the relevant blocks of code.

There is probably a better way to fix this.

---

3.

As mentioned above, Godot needs to be compiled against MacPorts-libcxx. I tried various ways of setting this nicely via flags and environment variables in the Portfile, but the only thing that seemed to work was editing /platform/osx/detect.py. Below line 108, which reads env.Append(LINKFLAGS=["-isysroot", "$MACOS_SDK_PATH"]), I added:

env.Append(CCXFLAGS=["-nostdinc++", "-I/opt/local/include/libcxx/v1"])
env.Append(LINKFLAGS=["-L/opt/local/lib/libcxx"])

---

4.

After the port has been installed, edit Godot's info.plist to change LSMinimumSystemVersion from 10.12 to whatever OS you're running.

---

Addenda

Addendum A.

I set the compiler to Clang 11 for possibly-better compatibility with macports-libcxx. I do not know if this was actually necessary. In the Portfile:

set clang_versions {5.0 6.0 7.0 8.0 9.0 11}

Addendum B.

To make Godot itself produce binaries (games) that are compatible with 10.11 and below, you need to also recompile the export templates. Reinstall Godot twice, with the below added to your portfile:

build.env-append tools=no

After each build, make sure the binary is linked to macports-libcxx via a relative path, such as via:

sudo port install dylibbundler
dylibbundler -p '@executable_path/../Frameworks' -d ../Frameworks -b -x Godot

Then replace the debug binary in the OSX template with your versions, and copy over the Frameworks folder with the macports-libcxx libraries. I can't figure out how to build a non-debug binary for the template.

---

Because of the level of non-optimal hackery involved (esp point 2), I don't personally intend to submit a pull request for any of this; these are just notes! 🙂 Let me know if there's a better place than trac for such things in the future.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Wowfunhappy:

2.

For a reason I wasn't able to track down, the lines:

#if MAC_OS_X_VERSION_MAX_ALLOWED < 101200
#if MAC_OS_X_VERSION_MAX_ALLOWED >= 101200

in platform/osx/os_osx.mm no longer have the desired effect; the compiler is convinced MAX_ALLOWED is always above 101200. I had to manually comment out the relevant blocks of code.

There is probably a better way to fix this.

This commenting out (removing) was committed in [b08699befa86acc41878c689093eb35d25aed0a9/macports-ports].

I suspect the reason for the problem is that platform/osx/detect.py sets -mmacosx-version-min=10.12 on x86_64 systems (while still printing an inaccurate message "Building for macOS 10.9+, platform x86-64"). The setting of -macosx-version-min should probably be removed from the build system since MacPorts already sets the equivalent MACOSX_DEPLOYMENT_TARGET environment variable the way it wants.

This would have been easier to notice if the build did not use silent rules; the portfile should disable silent rules (i.e. we should see each compile command and all its arguments in the log).

[Wowfunhappy (Jonathan)]

Excellent, I'm thrilled that someone who actually knows what they're doing had a chance to look at this!

I'm intrigued that the aforementioned commit reportedly works around compilation errors on 10.9, but does not appear to be using MacPorts-libcxx? Was that never actually needed?

It also doesn't appear to be editing info.plist?

[jasonliu-- (Jason Liu)]

I've been working on this issue for a while now, I didn't realize that someone had filed a Trac ticket. Some initial discussions took place in ​GitHub PR #12269. As Ryan mentioned, I just submitted ​GitHub PR #12893 earlier today to try to work around the issue.

I can further investigate whether there might be a way to remove any attempts to set -macosx-version-min by SConstruct and/or the python script. This might be a slightly better solution than simply ripping out the problematic code like I'm doing right now.

It's a good idea to turn off silent rules. I hadn't noticed that there were options to control it in the SConstruct file until Ryan mentioned it. I'll submit an additional PR to turn on verbose output for the build.

[Wowfunhappy (Jonathan)]

Fwiw, without modifications the Godot port does not appear to be compiling on 10.9 for me right now. Main.log attached. I don't remember if these are the same errors I encountered five months ago, but my guess would be that it needs macports-libcxx in order to work!

[jasonliu-- (Jason Liu)]

Replying to Wowfunhappy:

Fwiw, without modifications the Godot port does not appear to be compiling on 10.9 for me right now. Main.log attached. I don't remember if these are the same errors I encountered five months ago, but my guess would be that it needs macports-libcxx in order to work!

That wouldn't surprise me. Be aware that even though my ​GitHub PR #12893 might work around the preprocessor macro problem, it doesn't necessarily mean that the new Godot will run, or as you say, even compile. In its current state, my local Godot Portfile compiles successfully for me on macOS 10.11, but it crashes immediately upon launch (I'm obviously talking about after changing LSMinimumSystemVersion in info.plist... otherwise the app would have a circle-and-slash symbol). Since today is the first time that I'm seeing this Trac ticket, I'm working on incorporating the list of patches/workarounds you listed in your OP. Hopefully the addition of macports-libcxx might also help with my 10.11 crashing issue.

[jasonliu-- (Jason Liu)]

Replying to Wowfunhappy:

Fwiw, without modifications the Godot port does not appear to be compiling on 10.9 for me right now. Main.log attached. I don't remember if these are the same errors I encountered five months ago, but my guess would be that it needs macports-libcxx in order to work!

If you look at the build logs for ​10.10, ​10.9, and ​10.8, they are now getting the same errors as the log that you attached in comment:6. These errors are related to AppKit enums. With every new version of macOS, Apple renames, deprecates, or introduces new ones. In order to work around the issue, you (and by "you" I basically mean me, the package maintainer) basically need to map the enum that is causing an error to an equivalent one on whatever macOS you're on. I essentially had to do this in my Blender port: ​blender/files/old_appkit_compat/AppKit/AppKit.h. I expect to have to do the same to get rid of these errors for Godot.

@Wowfunhappy, it might help if you could send me the list of AppKit enums from whatever macOS version you are running (it seems you are on 10.9). This file should be located at

/System/Library/Frameworks/AppKit.framework/Resources/BridgeSupport/AppKit.bridgesupport

This bridge support file collects all of the enums from all of AppKit's submodules in one place. If you could add that as an attachment, that will help me to add the enums to my AppKit compatibility header. If the bridge support file doesn't exist on your version of macOS, let me know.

[Wowfunhappy (Jonathan)]

Done, let me know if you want any others, I run 10.9 natively but I have VMs of 10.4, 10.6–10.8, and 10.13 at my fingertips. :)

(I'm a bit surprised I didn't run into any AppKit issues when I compiled Godot? Or maybe I did and forgot to document that change, it does sound familiar, but that might have been for a different port.)

[jasonliu-- (Jason Liu)]

Replying to Wowfunhappy:

Done, let me know if you want any others, I run 10.9 natively but I have VMs of 10.4, 10.6–10.8, and 10.13 at my fingertips. :)

(I'm a bit surprised I didn't run into any AppKit issues when I compiled Godot? Or maybe I did and forgot to document that change, it does sound familiar, but that might have been for a different port.)

Hopefully just that one bridge support file will be enough. Based on the bridge support file you sent, AFAICT all of the the AppKit enum errors that are currently being generated should be taken care of by my AppKit compatibility header. Yet one more reason why I really should spend some time to get that thing added to the MacPorts legacy support package.

And the AppKit issues probably sound familiar because you yourself were the one who previously submitted a patch for some AppKit enums for Godot 3.2.3: ​godot/files/legacy-osx-defines.diff 😉

---

I would also like to point out that what you suggested in Addendum B probably isn't workable in the context of the Portfile. I have contemplated incorporating export templates into the Godot port so that people wouldn't have to download them after installing godot, but I came to the conclusion that it wasn't possible: I had previously asked around whether it's possible to have MacPorts repeat phases multiple times, and the responses I got was a fairly resounding "no, MacPorts wasn't built to do that". Instead, what I'm considering doing is to create one or more subports for the export templates.

In addition, at least with Godot 3.x, the export templates must be placed in your home directory for them to show up in the Godot editor's interface... so even if I did create a subport for the export templates, the best I could do is to have MacPorts place them into a shared location such as ${prefix}/share/godot/export-templates, and people would have to know to go there and copy the export template to their home directory. I've even submitted a ​Godot Proposal (#2565) to see whether future versions of Godot could allow placing the export templates in a shared location that would be visible to all users on a multi-user system.

[Wowfunhappy (Jonathan)]

And the AppKit issues probably sound familiar because you yourself were the one who previously submitted a patch for some AppKit enums for Godot 3.2.3.

Oh! Right, I'd fixed the problem in 3.2.3 before looking at 3.3.2. I didn't actually know what these were, just that it allowed Godot to build.

Instead, what I'm considering doing is to create one or more subports for the export templates.

Yes, I think that's the right approach! You might include some Notes in the Portfile, similar to how the Go port provides special compilation instructions for users on old systems: ​https://github.com/macports/macports-ports/blob/master/lang/go/Portfile#L123.

[kencu (Ken)]

The problem I saw with the general unrestricted use of your appkit redefines loose in LegacySupport was that every piece of software that ever tested for something to be defined, or tested if a given function existed, or tested if a window responds to a given selector, or ... did any kind of workaround at all in it for older systems support (and that is quite a lot of Apple-related software) ... was at risk of being very affected by your redefines in a way that I found very hard to predict.

Now how much that would or would not happen? Who knows? But that was the reason for caution, at the time.

Now, I have retired all my older Darwin systems and converted them all to Debian or Ubuntu, and even the PowerPC G5s can run qt5.13 and all the software that needs it. My Intel systems all run Ubuntu 21.10 at present. So I am not in this game of trying to make these older systems run smoothly, and you can feel free to go ahead with getting your changes into LegacySupport as you wish, if Chris will accept them.

[kencu (Ken)]

Oh, and I did mention at the time that sure, there could be YAT (Yet Another Toggle) added to LegacySupport to switch it on and off, if it came to pass that there were more than one or two ports that used it, to justify going to the trouble and added confusion.

[jasonliu-- (Jason Liu)]

Replying to kencu:

The problem I saw with the general unrestricted use of your appkit redefines loose in LegacySupport was that every piece of software that ever tested for something to be defined, or tested if a given function existed, or tested if a window responds to a given selector, or ... did any kind of workaround at all in it for older systems support (and that is quite a lot of Apple-related software) ... was at risk of being very affected by your redefines in a way that I found very hard to predict.

Now how much that would or would not happen? Who knows? But that was the reason for caution, at the time.

Indeed... In fact, as I'm working on the fixes in this ticket, I ran into a situation where the build was dying horribly with a bunch of "redefinition of macro as different kind of symbol" errors. It turns out that I have to account for the corner case where I'm performing the build using a macOS 10.12 SDK on a macOS 10.11 machine. So methinks caution is still somewhat warranted, even now. But now, after incorporating the wrapper into three relatively complex software projects, it may be ready for prime time.

Now, I have retired all my older Darwin systems and converted them all to Debian or Ubuntu, and even the PowerPC G5s can run qt5.13 and all the software that needs it. My Intel systems all run Ubuntu 21.10 at present. So I am not in this game of trying to make these older systems run smoothly, and you can feel free to go ahead with getting your changes into LegacySupport as you wish, if Chris will accept them.

Congratulations on going "whole hog" and transitioning those machines over to Linux! As an avid Linux user both personally and professionally, I commend you for making the decision to convert.

Oh, and I did mention at the time that sure, there could be YAT (Yet Another Toggle) added to LegacySupport to switch it on and off, if it came to pass that there were more than one or two ports that used it, to justify going to the trouble and added confusion.

Yes, I suspect that I would have to add some sort of option similar to the legacysupport.use_mp_libcxx switch that I've had to use in the fixes for this ticket, as suggested by @Wowfunhappy in his OP.

[jasonliu-- (Jason Liu)]

I've got some good news.

After implementing most of the tweaks listed by @Wowfunhappy in the OP, I've been able to get Godot to launch without crashing on macOS 10.11. Hopefully this also means that it will now also work on 10.10 and 10.9 as well. I'll address each point, just to make sure I've covered everything.

1. This was already implemented when I rewrote the Portfile to add the subport.

2. This was resolved in ​PR #12893.

3. This will be implemented as part of my upcoming PR.

4. This will be implemented as part of my upcoming PR.

AddendumA. Clang 11 was already added when I rewrote the Portfile to add the subport. However, I'm not 100% convinced that using Clang 11 is necessary in order to use macports-libcxx. When I successfully got Godot to work on my local machine, I performed the build (with macports-libcxx included) using Clang 9.

AddendumB. Discussed in comment:12 and comment:13.

Now, I just need to wait for ​PR #12976 to get merged, and then I can submit the PR that will hopefully close out this ticket.

[mascguy (Christopher Nielsen)]

Replying to jasonliu--:

After implementing most of the tweaks listed by @Wowfunhappy in the OP, I've been able to get Godot to launch without crashing on macOS 10.11. Hopefully this also means that it will now also work on 10.10 and 10.9 as well.

That's great news Jason, looking forward to the PR!

[Jason Liu <jasonliu--@…>]

In 820748c6ca89a5869df317d4305ba292f79bdd92/macports-ports (master):

godot: Fix builds for macOS <= 10.10

Closes: #63033