The "Pre-Built Binaries"

[OpenXTalkPaul]

I recently got another request for the "Pre-Built Binaries" that the 9.6.3 build process looks for that were previously stored on LC's servers ( but is now password walled off ) :
Credit/Thanks for these files go to Mark (Ah Ha Software ) Wielder:
https://drive.google.com/drive/folders/ ... sp=sharing
I'm going to also upload them to a repo on GitHub but here is a back-up copy on Google Drive for now.

[OpenXTalkPaul]

Just in case someone new comes across this thread...

The downloads link are the 'pre-built' files for Linux engine only.
We are still missing the corresponding files for other engines (Mac, Windows, etc.), if anyone has these binaries saved from previously building the macOS or Windows engines, please share them with us (all open source projects so that shouldn't be any problems).

I'm currently trying to replicate this list for macOS, building the missing library binaries from source (mostly via Homebrew package manager).

These are mostly fairly common libraries, some of these were already installed on my system.

[richmond62]

What of the 9.7 github repository?

[tperry2x]

What of the 9.7 github repository?

That does not include the prebuilts unfortunately. These are currently behind a login & password barrier on the livecode server.

Screenshot at 2024-02-05 11-10-05.png (57.27 KiB) Viewed 5788 times

[OpenXTalkPaul]

There IS this repo, that does have binaries: https://github.com/OpenXTalk-org/livecode-prebuilt/
But it doesn't look like it was kept up to date.
Release tab indicates that was last used for v6.7.11

[OpenXTalkPaul]

This might be a problem, can't build mysql (for libmysql):

TrynaGetMySQL.jpg (67.89 KiB) Viewed 5733 times

Probably using MacPorts would be better.

[tperry2x]

I personally don't think homebrew is the way to go with this. At least not initially.
Homebrew wasn't 'a thing' really as far as the engine was concerned - (well, that's not strictly correct. The engine source didn't really support it / was not built with it in mind) - is a more accurate statement.

We can always use homebrew in future, but I think the best option would be getting it to compile as intended initially.
We can only do this with access to the prebuilts directory, because that's what the Livecode engine source currently requires.
Without the required matching prebuilts, having the engine source in github is a bit useless.

(It needs to be the 9.6.3 / 9.7 binaries).
We can update the libs for bug fixes, but to stand a chance of checking compile targets, we initially need the correct prebuilts for the linker to succeed.

This is especially true on Windows, as the engine ties into a lot of old dependencies which need updating. If I have the correct prebuilts the engine compile process is expecting, I can always update the libs in place. However, first I need something to work with to stand a chance.

After that point, we can always update the gyp build process with hooks into homebrew or whatever - or replace gyp with macports (or something else entirely). But I'd like to get it to compile with the intended libs first, and go from there.

Also, bearing in mind that anyone who downloads the current LC source from LC's github page will need these prebuilts if they are wanting to take the engine in a new direction, they'd be stymied without them. In my view, not having access to them effectively closes the source of the engine as it's then incomplete, and putting them behind a login/pw barrier does not match up with the open source ethos in any way.

Anyway, without covering old ground that I've already gone over, I've currently got a few people looking - using a softly-softly approach, but the more the merrier as far as I'm concerned.

[OpenXTalkPaul]

I personally don't think homebrew is the way to go with this. At least not initially.
Homebrew wasn't 'a thing' really as far as the engine was concerned - (well, that's not strictly correct. The engine source didn't really support it / was not built with it in mind) - is a more accurate statement.

We can always use homebrew in future, but I think the best option would be getting it to compile as intended initially.
We can only do this with access to the prebuilts directory, because that's what the Livecode engine source currently requires.
Without the required matching prebuilts, having the engine source in github is a bit useless.

(It needs to be the 9.6.3 / 9.7 binaries).
We can update the libs for bug fixes, but to stand a chance of checking compile targets, we initially need the correct prebuilts for the linker to succeed.

I get what you're saying, we need to be able to compile the thing as-is (more accurately as-was) and then move forward from there, but without knowing the exact contents of those 'pre-built' archives, like the exact version and any build options used or modifications that may or may not have been made to any libraries source (in which case those modifications should've been published), then I agree we don't stand much chance of compiling as-was.

As far as using Homebrew, it builds -dev branches, so we should be able to use it to get the headers and .a file a compiler-linker would use. Of course if the Homebrew formulas don't have certain build options that the build may depend on (which I don't know any special build options are required for any of them), then we don't stand any chance (I'd say we still do stand some chance, might need a bit of luck) of compiling as-was.

I'm guessing here, we may need older versions of these libs (from around July 29th 2021) to match the contents of those archives, most likely the same versions used in those Linux libraries (unfortunately I think only a MAJOR version is required for ELF https://en.wikipedia.org/wiki/Executabl ... ble_Format , so I'm not sure how we could find out the MINOR versions).

MacPorts seems to be better for getting older and/or stable branches of libraries than Homebrew is.

As I've said in the past about concentrating on the xTalk language interpreter, I'm not against commenting-out some of these used in externals for SQL or XML and whatnot (and then working on replacements for those), but there are libraries needed for the engine itself like libSkia (which isn't available in a Homebrew formula).

At least we have the Linux Engine squared up.

[OpenXTalkPaul]

Just spit balling here, and it would probably be a prohibitively large amount of work, but we could use:

nm -D /path/to/libwhatever.so.<num>
-D refers to the dynamic symbols that are actually used for dynamic linking.

to find out what symbols are in a library, and make sure our built libraries have those symbols.

At least on macOS we don't need Chromium framework, one less thing to deal with.

[OpenXTalkPaul]

While doing other things yesterday, I had Homebrew running building as many libraries as I could match from the Linux version of that 'Third-Party' archive. By 'matching' I mean in name only. As you can see the Linux version the corresponding 'pre-builts' third party archive, they are dated from February 2021 (months before 9.6.3 release):

MatchPreBuilts.jpg (155.48 KiB) Viewed 5685 times

Pictured bellow them are some of the mac versions of same libraries ((X86_64, current versions built with default build options, built on macOS 11 'Big Sur').

[OpenXTalkPaul]

This seems to indicate the third party libraries that are needed.

https://github.com/livecode/livecode/bl ... e.gyp#L226

[tperry2x]

That's a nice find!
So, if we know the names of the files that should be in the '.tar.bz' files, I suppose we could recreate them if we can't get them any other way?

Not much mentioned in the way of Windows libs there at all? I expected there to be a long list of things not only for MacOS, but for windows too. So that's a bit puzzling.

[OpenXTalkPaul]

I spent some time today NOT watching 'the big game' (It's SuperBowl Sunday here in the States), instead switching over to Xcode and compiling whatever I could get to compile using those generated Xcode sub-project files. I think I have all of the 'third party' source directory built (debug builds). libOpenSSL is labeled _stub, I believe on macOS the engine uses the version of OpenSSL that is included with macOS instead? I did build the graphics libs, libCairo, and libSkia code .a archives which included those individual CPU feature optimized (like intel sse2 - sse42) files.
I really need to learn XCode better. I'm really just fumbling my way around there (there's probably some SuperBowl pun here).

DebugBuilds.jpg (286.49 KiB) Viewed 5674 times

Probably delete those 'host' files, the host is X86_64, and so is the regular target, which is why both versions are the same size.

[tperry2x]

That's certainly looking promising.
My thinking is, when we've got these, we could create the required '.tar.bz' files from them (omitting any files from the archive starting with a "." that the Mac will create), then create a "prebuilts" directory and post back to GitHub?

I'd like to see if they will allow the engine to compile properly, which they should do, under MacOS and Windows.

If they do, it would be great to allow anyone working with the LC engine source to be able to compile that project properly too.

[tperry2x]

Hi Paul,
I was just wondering if you'd made any headway with recreating the prebuilts at all?
I have got to the stage where I'm stuck at the compile of the engine on MacOS, as missing the expected prebuilts.

error-screenshot.png (637.5 KiB) Viewed 5543 times

(path changed to local path, picks up from a local folder, not from LC's server - but fails as I don't have it)

Specifically:
"Thirdparty-e5e050573c226f60acfbb9107c2b4aea853b0cbe-mac-Universal-PIC.tar.bz2"

[tperry2x]

I have just posted a "private" message to Heather Laine on this subject: the substance of which goes like this:
"I believe the pre-built binaries should be part of open source LiveCode, but they appear to be 'stuck' behind a paywall.

Well, not really a paywall as such - It doesn't ask for payment, but access is currently blocked

Please can you let me know why the pre-built binaries for LiveCode open source are not publically accessible.

Exactly that.

...the result [we await]).

Oh well, if we don't ask, we don't get.
It's worth a try. Otherwise I'll have to hope I get sent a few more links like before, from people who want to see the engine (and ultimately LC community edition / OXT / any other build you care to mention) carry on and be developed further.

[OpenXTalkPaul]

Hi Paul,
I was just wondering if you'd made any headway with recreating the prebuilts at all?
I have got to the stage where I'm stuck at the compile of the engine on MacOS, as missing the expected prebuilts.
error-screenshot.png
(path changed to local path, picks up from a local folder, not from LC's server - but fails as I don't have it)

Specifically:
"Thirdparty-e5e050573c226f60acfbb9107c2b4aea853b0cbe-mac-Universal-PIC.tar.bz2"

I can't be certain of what was in that ZIP file, but based on what was in the similarly named Linux pre-built files, I built the Mac versions of bunch of those libraries and uploaded them to GitHub here: https://github.com/OpenXTalk-org/OpenXT ... /mac/Debug

My thinking was that eventually I would to look to see what that .sh script is supposed to do with the zip file after downloading it, probably extract it somewhere, and then try to match the missing extracted files in that directory with my own builds and lastly patch the scripts to skip over the download/unzip part of it.
Another option is to just patch any missing library dependencies references for any missing libraries in the Xcode project(s) in its inclusions pane.

[tperry2x]

I can't be certain of what was in that ZIP file, but based on what was in the similarly named Linux pre-built files, I built the Mac versions of bunch of those libraries and uploaded them to GitHub here: https://github.com/OpenXTalk-org/OpenXT ... /mac/Debug

Thanks Paul,
Downloaded (https://downgit.cvbox.org/#/home?url=ht ... ac%2FDebug)
I will give this a go and see what I can recreate, and see it it works.

Do you also have the original files in this Debug folder, before any modifications? - just so I can restore the originals for the engine if need be?

[richmond62]

Something went 'funny' and my message was NOT recorded, so:

I thought I had posted this to you the other day, but it has not appeared in the records; so, forgive me if this is a repetition.

I believe the pre-built binaries should be part of open source LiveCode, but they appear to be 'stuck' behind a paywall.

I am not sure is this is correct.

Please can you let me know why the pre-built binaries for LiveCode open source are not publically accessible.

Best, Richmond Mathewson.

[tperry2x]

That seems to have come through originally
https://www.openxtalk.org/forum/viewtop ... 6964#p6964

All files gratefully received at this point. I've just recreated the tar.bz2 file
(Thirdparty-e5e050573c226f60acfbb9107c2b4aea853b0cbe-mac-Universal-PIC.tar.bz2)

I'll give this a go tonight at some point and see if it likes it when trying to compile the engine for MacOS.