Compiling from Source on macOS

[OpenXTalkPaul]

Over the weekend I just started looking into compiling the engine from source on macOS 10.14.6.
I was able to use gyp to generate the xcodeproj files (in "build-mac" which I uploaded to the repo) for building in Apple's XCode. The projects are setup for macOS 10.9 SDK compatibility. The problem with that is I'm running 10.14 and so have an Xcode that comes setup ONLY for targets 10.14+.
So for anyone else trying to do this here's what I've found as a workarounds instead of having to install old versions of macOS:
There's a backwards compatibility script here:
https://github.com/devernay/xcodelegacy
You can get the old macOS SDKs here:
https://github.com/phracker/MacOSX-SDKs
and old full Xcode releases here:
https://xcodereleases.com
and iOS here:
https://github.com/sunmean/iOS-DeviceSupport
https://github.com/anewcorp/iPhoneOS-Pl ... rImage-dmg

https://github.com/caodakeng/Xcode

[OpenXTalkPaul]

If you follow the macOS build instructions then you need a BUNCH of different Xcode versions 6.2,7.3, 8.2,and 8.3, install them all to a folder you create, they're all like > 5GB each, and then you can run a shell script that creates a symbolic link into whatever your current Xcode version is. I would've thought you only really need Xcode 6.2 (which contains the macOS 10.9 & 10.10 SDKs, the minimum os version for running v.9 is macOS 10.9)

[OpenXTalkPaul]

I should say If you’re trying to follow the Mac build instructions on the wrong macOS version, you won’t be able to. For one thing you can’t launch XCode 6.2 on newer versions of macOS such as 10.14, it won’t launch… on older OSX you won’t be able to launch newer Xcode versions, I’m sure there’s a sweet spot, maybe 10.13? You really only need the SDKs from those versions, sym linked into the XCode version that’s current for the macOS version on your system…
The point is just setting up to compile, at least on macOS is a royal pain in the ass.

[richmond62]

a royal pain in the ass

Not having a donkey that will make things even more difficult.

On the East side of the pond a rude word for bottom 's 'arse'. . . LOL
-

donkey.jpeg (34.32 KiB) Viewed 16396 times

-

AND, just to be a real pain in the donkey, my 2018 Mac Mini just does not
have the space to install 57 varieties of xCode . . .

[OpenXTalkPaul]

I don't have the space for it either, at least not on my system partition, which makes things more complicated.
Also, for Xcode 8.2 and 8.3 you need to have twice the space because Apple no longer packages Xcode as a simple dmg, they now use a signed compression format called Xip (not Zip), which can take a LONG time to extract. I fell asleep waiting.

The thing is I should only have to go through this once, because this is all just to extract about 5x 300mb SDKs, which I already know where to get separately (see link in first post in this thread). I'm following the LCC mac build guide to try to figure out exactly which SDKs are actually required. We should be able to do this much more efficiently thereafter, I could upload the whole finished batch somewhere with a shell script that makes the symlinks into, for one example, /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX10.9.sdk

[ernie]

Is there a pre-compiled binary version of OpenXTalk available for MacOS X Catalina?

I am not setup with Xcode to compile yet.

I do have LC 9.6.3 installed but I would rather work with OpenXTalk since LC dropped community support.

[OpenXTalkPaul]

Is there a pre-compiled binary version of OpenXTalk available for MacOS X Catalina?

I am not setup with Xcode to compile yet.

I do have LC 9.6.3 installed but I would rather work with OpenXTalk since LC dropped community support.

No, not yet anyway, what we have so far is just about all of the changes that remove the words LiveCode and replace it with either OXT, OpenXTalk, or more preferably something more generic like “an xTalk engine” or “The development environment (IDE)” or a Stack instead of “LiveCode Stack”. This involves things like rebuilding the syntax dictionary (which was also expanded in the process), along with a couple of IDE bug fixes, slight modifications, images removed or replaced, and scripts and GUI changes to support DarkMode in the IDE. All of these changes are on GitHub and can be applied to a copy of your existing Mac community install to turn it into OXT IDE, complete with new icons, etc. You simply replace the files inside the Mac app bundle, resources, tools, documentation, toolset, etc. with the coresponding named file/folder from the IDE repo.

If you build it this way you may have to do two things to get macOS to recognized as OXT and not a copy of LCC, zip the whole app bundle and then unzip it, which should get launch services to scan the file, get its icon associations, app info and such from the app bundle. If that doesn’t do the trick, you may have to rebuild the macOS Launch Services cache (the equivalent of “rebuild the desktop file” on macOS classic). Then when you launch OXT, reset your preferences in the preferences window, this should get OXT to build it’s own folders that allow it to coexist alongside of LCC (or any other LC version).


I’d like to have portable modified IDEs for all three platforms packaged up by Dec. 25th or maybe Jan 1st, that way people don’t have to do that sort of thing for themselves, the can just download and install OXT, after that release I’m going to be looking more at compiling the engines from source. I’d like to isolate and make a process for building just the engines, no externals, installer versions, or any of those peripheral things (some of which could be replaced or removed).

[tperry2x]

I'm actually going the other direction and downgraded a repurposed mac to 10.14 Mohave, the last macOS version that can run (and compile) 32bit code. I figure that's probably our best bet for compiling the engine on macOS.

Yes, I've got a mac mini that I'm trying this on for OSX compilation (want to retain 10.9 support). Also running on 10.14 for exactly that reason. You can install more versions of xCode on it with the 32-bit support, so it makes testing a lot easier.

Still getting just as many errors there as on the windows compilation efforts. It seemingly makes no difference if I try for a 'debug' / 'release' or 'fast' compilation.

compile-errors.jpg (541.23 KiB) Viewed 2116 times

If it helps, here's the xCode SDKs, extracted for you, that you need for MacOS compilation (link)

xCode and SDK setup.jpg (402.38 KiB) Viewed 2116 times

(this should probably all be in the "compiling from source" section).
edit: moved.

[tperry2x]

Have you tried compiling the source from previous releases?
I guess 9.7.x was more beta testing than it is release quality, they had just made a release a month prior to dropping 'community'.

I don't know if 9.7 was beta quality - it contains a lot of menu fixes judging by the release notes.

I've just been going back as far as I can, with the various versions of MacOS X I have here.
This is back in OSX 10.6.8, and LCC 6.6.6.
I get approx 1459 errors, + 188 warnings. The compile goes all the way to the end, but does not result in a valid ".app".

Screenshot at 2024-10-31 17-03-23.png (217.27 KiB) Viewed 1075 times

I wonder if the compile was ever set up to work without extensive insider knowledge of the process. It certainly does not seem to be documented. The sparse notes on the github pages do not go into extended details for when errors are produced. The most recent engine source does not mention which version of xCode and MacOS is the preferred compiler environment for MacOS. Likewise, I assume Visual Studio has to be from 2015?

In version 6.6.6 of the engine, it is mentioned that xCode 3.2.6 is used, which will mean MacOSX 10.6.8, hence my testing above.

I'm assuming MacOS 10.14 for v9.7 of the engine, as you need to install multiple versions of xCode now - and some of those are 32-bit only.

Perhaps someone who can get the compile to function could write a step-by-step how-to.

Oh, and just to clarify, this source is directly from livecode's github engine repo, with no modifications.

[OpenXTalkPaul]

In version 6.6.6 of the engine, it is mentioned that xCode 3.2.6 is used, which will mean MacOSX 10.6.8, hence my testing above.

I'm assuming MacOS 10.14 for v9.7 of the engine, as you need to install multiple versions of xCode now - and some of those are 32-bit only.

10.6 + LC CE 6.x is going further back then I would care to wrestle with.
I imagine signing certificates for all of that stuff are all long expired. I've had to roll the system clock back a decade+ with a few signed installer .pkgs to (or use the excellent tool Pacifist) get them to install.

I wouldn't be surprised if xCode 3.2.6 AND some earlier version such as 2.4 xCode is needed for some .SDK that was included with it, because it seems the Engine was continuously supporting somewhat outdated versions of macOS all along the way.

The last time anyone 'in the know' mentioned what version of macOS they were compiling on, Monte said they were compiling on macOS 10.12 (Sierra, NOT macOS 12.x), which I don't think was a mistake. macOS 10.14 (Mohave) was the last to still supported 32bit code, which as of LC Community 9.6.1 they were still compiling a 32/64 bit FAT binary for the Mac Standalone Engine, so I think it must be 10.14, or 10.12. The nice thing about Extensions is that of they're 'lazy linked' to Libraries / APIs, they still can support features of newer OSes.

[tperry2x]

Looking through github commits to the LCC source:
https://github.com/livecode/livecode/co ... d0cce17df6

# Menu items which don't have a mark now display correctly on Big Sur when running on ARM processors

Which leads me to believe that the 9.7.0-dp1 source in the github engine has the menu fixed for MacOS.
There's probably ARM support in there too already reading that.

https://github.com/livecode/livecode/co ... de8b31d+35

There are also fixes for big sur too:
https://github.com/livecode/livecode/co ... c6c465149f

[[ Bug 23119 ]] Fix unresponsiveness of engine when scrolling on Big Sur
This patch fixes an issue where the engine would become unresponsive when scrolling through text be clicking and dragging the selection beyond the bounds of the text field.

So, all very interesting - but you may all already be aware of this.
I have a fork (a backup????) of the engine here, however I'm not convinced it's the full copy of everything. I'm not 100% comfortable with all this unless I have a copy of it downloaded to my local storage and also a copy backed up in 2 locations too.

I have more faith in this online version, as that's what has been working for me so far (at least on Linux). When I have a working Mac and Windows compile, I'll aim to put everything into that folder so anyone can pick it up and produce a working compile (in theory).

[tperry2x]

I was able to use gyp to generate the xcodeproj files (in "build-mac" which I uploaded to the repo) for building in Apple's XCode.

Can you give me a direct link Paul, as I just can't find it.
I'd be interested in grabbing this gyp-generated folder, just to see if your version makes any difference.

Also, do you get the same number of errors in xCode when compiling that I do?
If not - can you give me a complete 7z'd directory that I can download and test please. I have a MacOS 10.14 mac mini set up here with all the xCode versions installed, symlinked, and ready to go.

[OpenXTalkPaul]

I was able to use gyp to generate the xcodeproj files (in "build-mac" which I uploaded to the repo) for building in Apple's XCode.

Can you give me a direct link Paul, as I just can't find it.
I'd be interested in grabbing this gyp-generated folder, just to see if your version makes any difference.\

Yes, as mentioned they were uploaded to the repo: https://github.com/OpenXTalk-org/OpenXT ... c/livecode

Also, do you get the same number of errors in xCode when compiling that I do?
If not - can you give me a complete 7z'd directory that I can download and test please. I have a MacOS 10.14 mac mini set up here with all the xCode versions installed, symlinked, and ready to go.

My laptop took a dump, so I'm trying to sort that now and back up some things from its drive, so I'll try to get to this later, but you can always download the whole repo as a zip from the repos webpage.

[tperry2x]

...but you can always download the whole repo as a zip from the repos webpage.

The entire(?) thing! - that would probably take me all night and into the early hours of the morning!

Just trying to download that build-mac folder. No idea what this cryptic squit is supposed to mean. I've exceeded some limit dictated down to me somehow? but this is the only thing I've tried to download from Github today.

except-when-you-cant.png (125.72 KiB) Viewed 883 times

How hard is it just to have a 'download folder' link.

You can download GitHub repos from their web UI, just not individual folders from a repo. I have a feeling that limitation was designed to prevent people from using it as if it were a free file hosting cloud service (although I'm sure there's people who still do that)...

Yes, me - for cases such as this.
For all intents and purposes, that folder is 'stuck' in github at the moment - and I have no way to download it.
This makes it not fit for purpose as far as I'm concerned. All of those downloader websites return a 403 error when trying to retrieve it. If you get your computer back up and running, I hope you have this folder stored 'locally' on there. If you can upload it to a free mega account, at least I can download that with no restrictions. That would be very much appreciated.

I'm putting together VMs of each successful compile - just so I know I've always got them. QEMU is currently my preferred mode of operation at the moment. I've made a Linux VM with the successful compile (which is the same as in my mega link). Currently coming in at about 10GB for the entire VM image.

The next step is to do the same for Windows, as I was so close to getting it working before. I filled up a 120GB SSD trying it, so will try again with a 250GB SSD instead. (edit: done)

Then, when I really want to give myself a headache, I'll save the mac version until last (which will probably have to be real hardware of some description - last paragraph here).

[micmac]

It is amazing what Tom and Paul do to revive Livecode for us !!!

Mic

[tperry2x]

I should mention though, that even getting the 9.7.0-dp1 build to compile on the mac, that would be really good and is my next goal. Whether that contains any menu fixes or not, will have to see. I might have to find a victim with Sonoma and see if I can spend all day crashing their mac for them

[richmond62]

No victims with Sonoma round these parts: but a willing victim with Sequoia.

Ready to expose my neck to the blade.

[tperry2x]

That's a very kind offer, but what I mean is a Sonoma+ mac, with all the xCodes, prebuilts, xCode SDKs and such - comes in at over 68GB - and I need to sit there, compile, try a build > make a standalone with a menu > does it crash (yes?)... repeat.

So I'd need real MacOS Sonoma hardware in front of me I think.
I might have someone's mac in mind - just depends if I can convince them at the weekend. A few beers might be in order.

Plus I have to deal with 32 show-stopping errors currently.
These are logic errors, memory leaks, and null pointer errors (these just might need setting to 'NULL' though).
The memory leaks are definitely something I need to address, and explains perfectly why you get the MALLOC errors on MacOS currently in the 9.6.3 engine.

compile-errors.png (1.02 MiB) Viewed 774 times

That needs addressing first before any ARM-type shenanigans.

[OpenXTalkPaul]

...but you can always download the whole repo as a zip from the repos webpage.

The entire(?) thing! - that would probably take me all night and into the early hours of the morning!

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.

I will say that as a free file hoster GitHub was significantly faster for m last night for downloading large (my appImage version for example) files than MEGA was, in fact my other bandwidth use of streaming to TVs was causing buffering when it got up to about 5 or 6 Megabytes/sec max DL speed.

[tperry2x]

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 (12.91 KiB) Viewed 787 times

(Mega web UI > Settings > Transfers)