Compiling from Source on macOS

[OpenXTalkPaul]

Sorry I have pretty good broadband I guess so I probably don't consider download time as much anymore as I should. I'll try to zip that folder up for you tonight.

Thank you, I'm not meaning to moan - just frustrating as being able to download should be a basic feature.

I will say that as a free file hoster GitHub was significantly faster for m[e] last night for downloading large files than MEGA was...

That's to do with how many parallel connections you have set for uploading and downloading. You can tweak that in settings > transfers. Set to a lower number to not max-out your bandwidth

Screenshot at 2024-11-05 06-14-27.png

I'm sure I could enable some Quality of Service / load balancing settings on the router too, but I'm usually OK with max bandwidth usage for max download speed. Was that a MEGA setting?

Here's that folder zipped up:

build-mac.zip

(1.64 MiB) Downloaded 111 times

All it is is the Xcode project files that were generated, however these are my current versions of the files, I'm not sure if I modified them in anyway since they were generated by gyp. The nice thing is Git / version control a bit like having a time machine back-up too, so I can always retrieve the versions I pushed right after generating them.

If I recall correctly I had to find an update version of gyp to run it on Python 3.x for BigSur. Also have an update for wkhtmltox in the repo that is needed to generate the release notes / guide manual PDF files.

[tperry2x]

Thanks for this Paul.
I've tried with your build_mac folder today, but it just says "completed" instantly, and does not attempt to actually compile anything. There's no warnings, no errors, but also no output.

I tried again tonight, with a fresh "config-mac" and let gyp do it's thing. It runs through and makes the xcodeproj files with no errors. I open xCode and the engine.xcodeproj and try to step through each error. There's just so many null_pointer errors, memory allocation errors... I could go on. I've spent 4 and a bit hours on this tonight, and I'm done with trying - at least for a while.

I wonder what LC did to fix all those memory allocation errors I'm seeing. It also comes up with "ld -unknown option -platform_version", and I have no idea what that is supposed to mean. (something to do with the linker)??

The mac source seems to be the hardest to compile by far. The code also contains plenty of errors, so I'm not sure if the issue lies with Gyp at this point on MacOS - rather there are issues within the source.

What makes it so frustrating is the amount of pre-setup of the environment you have to do - just to get this far. I have the feeling I'm close, but not close enough - and sorting out all those memory bugs, that's a task in itself.

[tperry2x]

So, a bit further ahead now.
I've fixed all the malloc errors (memory allocation null pointers), however there's still two major errors I'm stuck on.

I might have a fix for the first one, but the second one:
"unknown option: -platform_version" might cause me a larger issue.

So, this morning I thought I'd try consulting ChatGPT on the issue:

hmmm.png (95.45 KiB) Viewed 4479 times

As far as ChatGPT is concerned, the error in "gentle" > the Mach-O linker is caused by needing xCode 11. But then, if I'm thinking of attempting Arm builds on MacOS, I should be thinking about instead using xCode 12.5 (which in turn, needs Big Sur).

However, for the time being, it seems to think I can use: "-macosx_version_min 10.9" instead. So I'll try this a bit later in xCode 10.1 *which seems to be the sweet-spot so far. (Rapidly filling up a 250GB SSD on the mac mini trying this, but that's all that mac is dedicated for at the moment).

It's so close...

[tperry2x]

If nothing else, I'm drastically reducing the amount of errors on the mac build.
Down to 1 major show stopper and 2 warnings now.

Screen Shot 1.png (769.34 KiB) Viewed 4458 times

[OpenXTalkPaul]

If nothing else, I'm drastically reducing the amount of errors on the mac build.
Down to 1 major show stopper and 2 warnings now.

Screen Shot 1.png

Seems like you're so close, awesome! Bravo for doing this work!

I think that is Unicode standards organization file it's referencing there....
Yup (overview from AI):

The ICU4C package is a set of C and C++ libraries that provide Unicode and globalization support for software applications. ICU4C is part of the International Components for Unicode (ICU) project, an open source project that offers Unicode services on many platforms. ICU4C is used to fill in gaps in support for Unicode and text handling services in C and C++ languages and operating systems.

ICU4C provides a portable foundation for applications to use for software globalization. It includes support for:
The latest version of the Unicode standard
Character set conversions
Locale data
Language sensitive text collation
Regular expression matching
Resource bundles
Date, number, and message formatting
Calendar specific date and time manipulation
Text boundary analysis

Several operating systems include ICU as a standard or optional package

ICU4C is the actual package name.
Here's the docs pages from their GitHub repo: https://unicode-org.github.io/icu/userguide/icu4c/
And the source code repo: https://github.com/unicode-org/icu
And the Homebrew formula for it: https://formulae.brew.sh/formula/icu4c@76

Code: Select all

brew install icu4c@76

I think I actually have the .dat file mentioned in that screenshot, not sure where I got it.

[micmac]

Paul...

What is your profession?

Mic

[tperry2x]

Thought I'd solved it, after pointing towards the ICU file, it moves onto final configuration stage, then comes back with a load more errors.
Seems to have not pulled everything from git (no surprise there).
Ho hum.

Screen Shot 1.png (350.24 KiB) Viewed 4423 times

(I've had to update so so so much to get to this point, none of it documented)

Screen Shot 4.png (934.25 KiB) Viewed 4421 times

Going to take a break from this, as it's soul destroying - quite frankly.

[OpenXTalkPaul]

Paul...

What is your profession?

Mic

I work in graphic arts / print production, coding is 100% hobby for me.

[tperry2x]

Hmm, this is as far as I've got this evening. Had enough at the moment:

Screenshot 2025-01-23 at 11.06.36 PM.jpg (962.17 KiB) Viewed 1671 times

It's likely I'm barking up the wrong tree anyway, because I have a theory that the engine will only compile under xCode 11.3 (highest). So it's probably pointless trying it with xCode 16.2

(After I give it a go in xCode 11.3, I will have tried pretty much every version of xCode from 8 upwards).
I know the version of xCode seems to matter, as there's over 600+ errors in xCode 12 with it, but only 7 errors when running the same compile test in xCode 16.2.

Thing is, xCode 11 won't run in Sonoma - so I'll probably have to run MacOS Catalina in a VM, then try and do the compiling there. (I need to keep the mac on Sonoma so I can test the broken menu situation in standalones)...

It all feels a bit of a codge.

Screenshot 2025-01-24 at 10-28-03 codge at DuckDuckGo.png (16.46 KiB) Viewed 1652 times

...or just say to mac users 'run it in wine'.

[tperry2x]

I since stumbled upon this, and here's an image version in case it won't load for you (I tried multiple browsers before that URL loaded anything at all):

eh.png (387.68 KiB) Viewed 1650 times

If you can follow that, good luck.

[richmond62]

As that is:

1. for deployment to iOS (probably NO chance of that with Open Source OXT),

and

2. It refers to LiveCode 9.6.9

I don't feel it may be relevant to OXT's situation.

[tperry2x]

I know that diagram is about as clear as mud, but the point is mentioning what versions of xCode will run in which versions of MacOS. However - not as straightforward because it just seems there were only about a handful of people on the planet who ever tried to compile the engine for MacOS with their own changes.

Information is sparse.

So much so, I'm thinking of automating a wrapper and running a linux version of OXT Lite within OSX using this method. The process would just need to be streamlined.

[richmond62]

So much so, I'm thinking of automating a wrapper and running a linux version of OXT Lite within OSX using this method. The process would just need to be streamlined.

Very clever, I'm sure: but would that be able to hive off a Mac standalone that ran on Mac.

I seem to recall that with LC 9.x a Mac standalone built on Windows or Linux would NOT run on Macintosh . . .

[tperry2x]

Probably not, but the alternative (at the moment) is having an engine that stops at 9.6.3 on the mac while the Windows and Linux ones continue.

[richmond62]

but the alternative (at the moment) is having an engine that stops at 9.6.3 on the mac

Personally, and selfishly, that would not bother me.

Whether running OXT for Windows in WINE, or OXT for Linux in some other sort of 'wrapper': the inability to compile standalones for Macintosh is a killer.

[tperry2x]

...the inability to compile standalones for Macintosh is a killer.

Coming to a mac near you in the next Apple MacOS update (when they decide that ONLY stuff from the Mac App Store are valid applications).

I'm only half joking.

The way forward at the moment then, is to find out why Mac standalones don't get created properly in Wine. I can build a perfectly valid MacOS standalone on Linux, just needs chown +x set when it gets over to the mac. (Well, I say that - probably something else blocking it after anything past MacOS 10.15) - take your pick, there's about 8 background system-level-processes that run in MacOS constantly that are in charge of blocking and denying apps run now.

(anyway - yes, I just built this stack on Linux for MacOSx64), copy it over to the catalina 10.15 mac, and it's all good). No terminal commands or messing about with it required at all

test-in-10.15-from-linux.png (171.31 KiB) Viewed 1584 times

MacOS is becoming more and more closed off, with no in-roads for anything except Apple's pre-approved apps. Some people like that, most don't even know - or don't care enough, so it'll continue to happen. Only small developers, open source projects, and people who care about NOT paying subscriptions are the ones who will feel the pinch.

These permissions are the tip of the iceberg, and more headaches are to come - I mean the amount of measures that exist in newer versions of MacOS essentially getting to the point where it's impossible to run anything bespoke - that's not from the App Store.

I don't see a way around that right now, so plist changes are important, but there are larger issues at play (in my opinion).

Edit:
It might seem like I'm sounding cheesed-off with Apple right now. (That's mainly because I am).

I'm messing around trying to compile the engine on MacOS, and just being met with endless errors.
(So much so, I may try another route)

Why (when you open an xCode project intended for version 6 of xCode -- which happens to be our 'beloved' engine source, does xCode not produce a prompt to convert the xcodeproject up to a newer version and replace all the syntax that might have changed between different versions?). I'm sure most of the errors I'm seeing is because of disparate xCode versions being used. Where are the notes saying which version of xCode this is supposed to be compiled in? There aren't any [well, kind of*]. I'm guessing it's xCode 11.3(.1?) Does .1 make a difference??

I'm more inclined to stick it all in a wrapper of some kind and get MacOS to run that reliably - but I've given this some careful reflection. As much as I'm going on about the engine source, and the state of it... I think the hurdle I'm really going to continually come up against (time after time) is the MacOS itself.

[**]
LC DO mention that the source expects each version of xCode 6.2.1, 7.2.1, 8.2 and 8.3 to be installed and run at least once. Therein lies the problem. xCode 6.2.1 requires MacOS 10.9.4. It won't run under a modern version of the MacOS, so you cannot get it to open to download the extra parts it needs and integrate it with the rest of the dev environment.
It's probably that this is just severely out of date, but simply having the SDKs in place, and symlinked is not enough.
Has <anyone> got this to compile on a recent version of MacOS, or have they resorted to compiling it in a OSX 10.9 Virtual Machine (or elderly mac?)

I should mention, I've tried both of those options - just seeing compile errors (mentioning invalid syntax and unused variables) - which stops the compilation effort in it's tracks.

Going back over what I'd already tried, this was xCode 11 in MacOS X 10.14, and hit compile issues (this time with 'gentle' on the final compile section). Each version of xCode gets to a different point, even though the source files I'm using to compile are identical.