the dreaded 64-bit compile

Moderators: heatherlaine, Klaus, FourthWorld, kevinmiller, LCMark

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: the dreaded 64-bit compile

Post by mwieder » Thu May 09, 2013 12:11 am

Step 1:

I cloned a new local repository (with recurse-submodules) from the runrev/livecode master branch and did a make all.
This failed with a "couldn't find hashedstrings.cpp" error.
I copied hashedstrings.cpp from my existing repository to the newly-cloned one and compiled everything on my 32-bit system except for the server, which fails with
"/usr/bin/ld: cannot find -lrt"

Switched to the develop branch and found the same thing.
So there's still a problem with the hashedstrings.cpp file on the master and develop branches of the main repository.
Either the file should be resurrected or else it's no longer necessary and should be dropped from the make files.

ricochet1k
Posts: 39
Joined: Tue Apr 23, 2013 1:30 am

Re: the dreaded 64-bit compile

Post by ricochet1k » Thu May 09, 2013 2:10 am

You need this commit: https://github.com/runrevmark/livecode/ ... 0a62e1dc6f

That is not on either the master or develop branch yet. Use runrevmark's feature-linux_x64_2 branch with the feature-linux_x64 branch for all the submodules.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: the dreaded 64-bit compile

Post by mwieder » Thu May 09, 2013 2:21 am

Matt- this was for the 32-bit build, so I explicitly did *not* pull the 64-bit stuff.

ricochet1k
Posts: 39
Joined: Tue Apr 23, 2013 1:30 am

Re: the dreaded 64-bit compile

Post by ricochet1k » Thu May 09, 2013 2:46 am

I get that, but there are general fixes in that branch, not all of it is 64-bit only. Plus, it's good to test that 32-bit builds still work with it.

That and runrevmark was specifically asking about the new 64-bit code, since you are one of the developers who has worked on it in the past.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: the dreaded 64-bit compile

Post by mwieder » Thu May 09, 2013 2:59 am

Yep - I'm at my 64-bit machine now, so I'm off to pull the latest.

But my point about the 32-bit stuff is that it should compile off the shelf (at least the master branch) and it doesn't.

ricochet1k
Posts: 39
Joined: Tue Apr 23, 2013 1:30 am

Re: the dreaded 64-bit compile

Post by ricochet1k » Thu May 09, 2013 6:05 am

I see. Odd that that wasn't tested better before the release. Is there an internal RunRev test suite?

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: the dreaded 64-bit compile

Post by mwieder » Thu May 09, 2013 6:27 am

Don't know.

But here's what I've got trying to compile on my 64-bit system:

I pulled the latest from runrevmark (I see what you mean about there being other changes besides the 64-bit stuff) and got
../../rules/archive.linux.makefile:6: *** Environment Makefile not included!. Stop.

So I pulled your makefile tabs fix and I still get the same thing.

Now, I can see what's going on... the thirdparty makefiles aren't including the environment.linux.makefile the way the engine makefiles are.
So the next question is... did I miss a commit somewhere along the line? I pulled runrevmark/thirdparty already. Everything seems up to date.
But there's no way it's going to compile with that include line in all the thirdparty makefiles.
I can fix that locally, but a commit must exist for that somewhere if you all are getting proper compiles.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: the dreaded 64-bit compile

Post by LCMark » Thu May 09, 2013 9:57 am

@mwieder: I'll pull in the x64 branch into 'develop' later on today - I didn't have a chance last night and hopefully that will solve (most of?) the issues.

In regards to the errors you are getting - for 32-bit I think the way we build the distributions masked the 'hashed_strings' problem in the current master... We build using VMs sharing a common folder so if one of the platforms has made 'hashed_strings.cpp' already then the Linux build finds them (really the derived files need to be moved to be created in _cache/platform).

In regards to the 64-bit issues - the submodules need to be referencing the runrev/* ones rather than mine... There should be a feature-linux_x64 branch in each of them.

I'm not sure about the '-lrt' thing - that must be a difference in Linux distro... It compiles on Ubuntu 6.06 at least. Can you check to see if you have a 'librt.a' and/or 'librt.so' in your lib path?

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: the dreaded 64-bit compile

Post by LCMark » Thu May 09, 2013 2:46 pm

Okay I've now merged the feature-linux_x64* branches into 'develop' on the runrev repo's. Things seem to all build fine here from a fresh clone on linux (32-bit Ubuntu 6.06 / 64-bit Ubuntu 12.04) [ just remember to checkout 'develop' in the main and submodule repos ]. Any issues you guys have now will hopefully be related to Linux distro differences which we can now hopefully sort out more easily :)

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: the dreaded 64-bit compile

Post by mwieder » Thu May 09, 2013 4:24 pm

As cleanly as I could try to make this:

git clone --recursive git://github.com/mwieder/livecode.git
cd livecode
git branch develop
git pull --recurse-submodules git://github.com/runrev/livecode.git
make all

./../libcore/include/core.h:214:55: error: ‘operator new’ takes type ‘size_t’ (‘long unsigned int’) as first parameter [-fpermissive]

git checkout develop
git pull --recurse-submodules git://github.com/runrev/livecode.git develop
git pull --recurse-submodules git://github.com/runrev/livecode-thirdparty.git
...fix the merge conflicts in owner, .gitignore, .gitattributes

../../rules/archive.linux.makefile:6: *** Environment Makefile not included!. Stop.


Tried a clean build, ignoring my fork entirely...

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

...same results.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: the dreaded 64-bit compile

Post by LCMark » Thu May 09, 2013 4:34 pm

@mwieder: Here's what worked for me (to test in a clean repo):

git clone --recursive git://github/runrev/livecode.git
git checkout develop
git submodule foreach git checkout develop

I couldn't get either checkout or pull to recurse correctly to the submodules, so that's why I just use submodule foreach.

For my fork I did something like (I have a 'runrev' remote reference in runrevmark/livecode.git):

git fetch runrev
git submodule foreach git fetch
git checkout develop
git submodule foreach git checkout develop
git submodule foreach git pull

Hope this helps!

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: the dreaded 64-bit compile

Post by mwieder » Thu May 09, 2013 5:35 pm

From a clean repo 32-bit (slightly corrected procedure):

git clone --recursive git://github.com/runrev/livecode.git
cd livecode
git checkout -b develop
git submodule foreach git checkout develop

./src/ide.cpp:405:29: fatal error: hashedstrings.cpp: No such file or directory

64-bit - while trying to compile sslstubs:

../../prebuilt/Revolution.lnx: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: the dreaded 64-bit compile

Post by LCMark » Thu May 09, 2013 7:03 pm

@mwieder:

The 'hashedstrings.cpp' problem is puzzling - this is built by a rule in Makefile.kernel-development IIRC. As I said my Linux distro seems to create it fine (I even double checked by making sure it wasn't there before doing a full build). Not sure what to suggest - you should be able to invoke the rule manually with an appropriate 'make' I think then it should be fine. Could it be a difference in 'make' version?

The 64-bit problem sounds like an issue with 32-bit libs on your 64-bit system - 'Revolution.lnx' is a 32-bit linux engine. I had that problem on a fresh install of ubuntu, but ensuring the 32-bit compat stuff was installed solved the issue.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: the dreaded 64-bit compile

Post by mwieder » Thu May 09, 2013 8:51 pm

32-bit:

No luck. The hashedstrings.cpp file isn't getting generated. I've got the original copy from my initial fork, but if I rename it my local build fails as well.

64-bit:

Urgh. I forgot that I was working in a VM instead of my native system. Had to load a lot of dependency dev libraries (and the ia32lib stuff, as you mentioned).
Now I get as far as the MySQL build, where the link fails with a lot of undefined references to things like

initialise_weak_link_crypto
initialise_weak_link_ssl
SSL_CTX_free

I do have the libcrypto and libssl libraries loaded and I see the libcrypto and libssl libraries in the prebuilt folders (both 32- and 64-bit versions).

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2695
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: the dreaded 64-bit compile

Post by mwieder » Thu May 09, 2013 10:54 pm

The magic incantation

Code: Select all

git pull --recurse-submodules origin develop
where origin is git://github.com/runrev/livecode.git
resulted in a successful 32-bit build, minus the server due to the failing "cannot find -lrt"
Apparently the foreach incantation didn't grab these.
But it's progress.

Post Reply

Return to “Engine Contributors”