Linux PPC build?

[richmond62]

As RunRev appear to be "on the cusp" of abandoning support for PPC Macintosh systems,

How many users of Livecode who use PPC Macs on a regular basis would like RunRev to make a Linux PPC build available.

Recently somebody on the use-list said something about 10 years being the max utility of a computer.

However others have mentioned eMacs running Mac OS 10.3 (support for which went after RR/LC 4.0), I run several G3 iMacs running Mac OS 10.4

The main reason I still use those G3 iMacs is:

1. I have ONE machine to run all the 3D software (Bryce, Poser, et al) that released Mac OS 9 versions FREE when Mac OS X came along.

2. Reliable machines that don't have such a socking great footprint on a school desk and look a whole lot nicer than grey or black boxes with monitors on top.

I have tried various PPC types of Linux on these machines with good results: were a Linux PPC version of Livecode available (or, at least, a version of Livecode running on Windows, Linux Intel or Mac Intel
that could produce Linux PPC standalones, I would not hesitate to change them over to Xubuntu PPC forthwith.

LC_gadfly.png

[LCfraser]

Hi Richmond,

Talking unofficially (as if I ever do anything else ), it shouldn't (in principle) be any harder to build LiveCode for PPC Linux yourself than building it for the RaspberryPi (but with the massive advantage that PPC machines are probably fast enough that you don't need to cross-compile). Again, there would be difficulties with some of the pre-builts we supply but nothing insurmountable.

If I get some time, I might have a go at it myself (I have a G5 PowerMac at home that doesn't do much these days) and I'll let you know how I get on. An interesting experiment would be whether 64-bit PPC works on Linux; Mark Wieder put in a fair amount of leg-work getting it working for 64-bit x86 so it ought to be possible...

Regards,
Fraser

[mwieder]

Well, it sounds like a ppc linux build might be a useful thing, but it's nothing I'm going to take on, at least not in the short term. I don't have any ppc machines running linux, in fact I have only one ppc machine at all, and it's sitting in the attic gathering dust.

So what would be necessary is to build from source on a ppc machine and cross fingers hoping that the required libraries are all in place and that there aren't any problems with the prebuilt stuff. There would certainly be a limited audience for such a thing, and it's nothing I feel like rushing around to try to bring to life. I would suggest, Richmond, that you grab the source from github and try to make it yourself on one of those linux ppc computers.

[richmond62]

One of the things I find confusing about the Source Code for Livecode is that I am used to downloading tarballs and playing around with them, and I find the GitHUb thing
extremely confusing.

What chance of a Tarball?

[mwieder]

Close to zero.
Using git allows you to keep up with updates to the source, so using a tarball would be a big step backwards.
You can achieve the same effect as downloading the tarball and unarchiving it somewhere with one line

Code: Select all

git clone https://github.com/runrev/livecode.git

although if you have in mind making changes and contributing them to the source you should probably create an account, fork the original source, and then clone the fork.

[monte]

Close to zero.

Not that close:

Code: Select all

curl -L https://github.com/runrev/livecode/tarball/master | tar zx

Although you are much better off learning git for which I would recommend reading this open source book: http://git-scm.com/book

[mwieder]

Well, I didn't mean to imply that you couldn't do it, just that it isn't likely to appear on the github site.
While you can make the tarball yourself, I don't see any gain from doing so.
Plus you lose the advantage of being able to grab updates through git.

[monte]

Sorry for the confusion.

That url https://github.com/runrev/livecode/tarball/master will download a tar ball of the current master branch. You can also get tags: https://github.com/runrev/livecode/tarball/6.5.2

It won't include the submodules though so yes you are right that it's much better to use git:

Code: Select all

git clone --recursive https://github.com/runrev/livecode.git

[mwieder]

It's not just the fact that you'd miss the submodules.
You'd be losing any advantage of using github.

A tarball would just give you a time capsule of the source.
If anyone made any changes you'd have to grab a new tarball, unarchive it somewhere else, and then go through the painful task of figuring out what changed and merge in any changes you'd already made.

Using git you'd just download the latest changes and merge them in one swell foop.

[monte]

Agreed.. I wouldn't use the tarball api unless it were a situation where I didn't care about updates or history etc. For example, my heroku build pack for lc uses the tar ball api to get the latest revIgniter. In richmond's case where he's likely to want to at least keep pulling the master branch if not checking out some of the feature branches then definitely git is the only way to go.

[richmond62]

Thank you very much, Monte, for the GIT book link.

Thank you, Mark, for the Tarball link.

Gosh, am I going to have a busy weekend.

[richmond62]

So, I download the tarball (onto Ubuntu INTEL) and follow the building instructions and end up with a version of Livecode.

Now, what I don't understand is why I cannot just download the same tarball onto an Ubuntu PPC machine and do the same thing?

I am writing this because I am not going to spend the time and effort to get an Ubuntu PPC distro going on the only PPC Mac I can
spare at the moment (macMini PPC) unless I know what I have to do subsequently.

Presumably there is quite a lot to be done, otherwise there would be absolutely no need to be having this discussion at all; it would just be a case of "download the tarball, untar, ./compile, make, make install and Bob's-yer-Uncle".

[LCfraser]

Hi Richmond,

The problem is the same problem as compiling for the ARM-based RaspberryPi: as part of the compilation process, a pre-built binary copy of LiveCode (actually, Revolution!) gets run to generate some of the source files. Because these pre-builts only exist for Mac-x86, Mac-PPC, Linux-x86 and Windows-x86 these files will fail to be generated and the build process will fail.

The "path of least resistance" solution is to copy the files in question from an x86 machine to the PPC machine (you have to build on the x86 first in order to generate these files in the first place). The files in question are:

engine/src/linuxstubs.cpp
engine/src/startupstack.cpp
engine/src/encodederrors.cpp
engine/src/hashedstrings.cpp
engine/include/revbuild.h
thirdparty/libopenssl/src/sslstubs.cpp

(At least in the 6.5.x series).

Because this problem comes up for the RPi as well, it might be worthwhile for me to create a branch on github that contains these files pre-generated to avoid the build-on-x86-and-transfer rigmarole. I'll put it onto my ToDo list (which, unfortunately, is rather long at the moment but this job is small and might go near the top). When/if this happens, I'll post a link to the branch in question so you can build from there.

[richmond62]

OK: but where should I put those files once they are on the machine running Linux PPC?

[richmond62]

The build instructions for Linux require one to have the following "bits and bobs" installed on one's system:

* make
* gcc
* g++
* libX11-dev
* libXext-dev
* libXrender-dev
* libXft-dev
* libXinerama-dev
* libXv-dev
* libXcursor-dev
* libfreetype6-dev
* libgtk2.0-dev
* libpopt-dev
* libesd0-dev
* liblcms-dev

running through these on UbuntuStudio 13.10 with Synaptic I was surprised to find that libXv-dev, libpopt-dev, libesd0-dev, and liblcms-dev were not present.

I also found that when those were set up to install various other dependencies ended up being installed as well.

I installed those into my system.

at which point I did a CD into the untarred tarball directory and did a

MODE=release make development

and got this in my terminal:

richmond@richmond-OptiPlex-745:~/Desktop/Tarbaby/runrev-livecode-4df76f7$ MODE=release make development
make -C ./thirdparty/libz libz
make: *** ./thirdparty/libz: No such file or directory. Stop.
make: *** [libz] Error 2

I'm obviously missing something; my "thirdparty" directory is empty . . .

Should I have the "shopping list" of 'bits and bobs' in that directory rather than installed in my system?

Trying to be CLEVER (not a good idea) I created an empty directory inside "thirdparty" called "libz" and got this:

make -C ./thirdparty/libz libz
make[1]: Entering directory `/home/richmond/Desktop/Tarbaby/runrev-livecode-4df76f7/thirdparty/libz'
make[1]: *** No rule to make target `libz'. Stop.
make[1]: Leaving directory `/home/richmond/Desktop/Tarbaby/runrev-livecode-4df76f7/thirdparty/libz'
make: *** [libz] Error 2

So, it would seem that, as well as needing some libraries in the "thirdparty/libz" directories I need some sort of instructions there as well.