the dreaded 64-bit compile

[ricochet1k]

I remember seeing a fix for the hashedstrings.cpp problem in runrevmark's repo.

[mwieder]

Hmmm... I can pull that in, but the master branch on the renrev repository really should compile off the shelf.

[ricochet1k]

If it's a Makefile dependency bug, then it might build or not depending on the -j option you feed to make. That's how I found the few that I did: by accident.

[ricochet1k]

So, I did some investigation and it appears that make isn't happy about tab being used as indentation when it's not part of a rule, such as between ifeq and endif, that's what's causing the "recipe commences before first target" error.

@runrevmark: The thirdparty Makefiles need to include the environment file as well.

[mwieder]

Yeah, I fixed all the thirdparty makefiles, which is what prompted me to start a clean compile straight off the master. Figuring maybe I missed a pull somewhere along the way.

[ricochet1k]

You know, I bet runrevmark fixed all of the thirdparty makefiles and just forgot to commit/push because they're in a submodule.

[mwieder]

I bet you're right - I made sure to do a recursive pull, but it didn't affect the thirdparty stuff.

[ricochet1k]

Actually, he didn't forget, something's just linked up wrong. The fixed branch is here: https://github.com/runrev/livecode-thir ... -linux_x64

[mwieder]

Well... wait... runrev/feature-linux_x64 is ahead of runrevmark/feature-linux_x64_2?
And now it's a weekend and we'll probably have to wait until it's Monday in Edinburgh for this to get straightened out...

Update: OK, I see. I have to pull in the feature-linux_x64 commits to get just the thirdparty stuff.

[LCMark]

Okay - so there shouldn't be a feature-linux_x64 branch in the main runrev repo yet as I haven't pulled it in there (I didn't want to make a mistake with git manipulations in that repo, so did the work in runrevmark/feature-linux_x64_2).

The runrevmark/feature-linux_x64_2 branch references the submodules in the runrev/runrev-ide, runrev/runrev-prebuilt, runrev/runrev-thirdparty repos. So if you fetch the runrevmark/feature-linux_x64_2 branch then checkout the runrev/feature-linux_x64 branches in the three submodules it *should* all work...

Sorry about the confusion :S

Edit: So I just checked here with the following:

Code: Select all

git clone --recursive https://github.com/runrevmark/livecode.git livecode-test-x64
cd livecode-test-x64
git checkout feature-linux_x64_2
git submodule foreach git checkout feature-linux_x64

And it seems to compile fine on my 32-bit (Ubuntu 6.06) and 64-bit (Ubuntu 12.04) VMs. So... if you substitute the clone for fetching the feature-linux_x64_2 branch from runrevmark/livecode things should go smoothly...

(This is assuming your forks reference the runrev repos for submodules, rather than your own forks of them).

[LCMark]

@ricochet1k, @mwieder: Did you guys get the linux_x64_2 branch working okay in the end? If so I'll merge it into develop. There's still some work to do on the standalone builder, but I did get as far as being able to produce a 64-bit Linux installer

[ricochet1k]

I still had to make a few tweaks, such as adding #include <glib.h> to lnxspec.cpp and converting tabs to spaces in archive.linux.makefile and environment.linux.makefile (make doesn't like tabs used for indentation, only for rules). I thought I had to do something about the system libcrypto conflicting with the included libz, but I don't see that change listed anymore. After those changes, everything built successfully for me.

I'm building on a somewhat bleeding-edge Arch Linux distro though, so take that with a grain of salt.

EDIT: The fix for the makefile tabs is here: https://github.com/ricochet1k/livecode/ ... efile-tabs

[mwieder]

@runrevmark: sorry, I got swamped with work and haven't been able to get back to it. Hopefully tonight.

[LCMark]

@ricochet1k: Cool - I'll merge in the makefile changes and add in the include to be on the safe side.

@mwieder: No worries - pretty busy myself at the moment (perhaps a slight understatement ) with conference prep, so haven't had much time to look at merging in pull requests.

[mwieder]

@runrevmark: why don't you go ahead and pull the changes into the develop branch. That way there'll be only one place I need to pull from tonight.