the dreaded 64-bit compile
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: the dreaded 64-bit compile
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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- Posts: 39
- Joined: Tue Apr 23, 2013 1:30 am
Re: the dreaded 64-bit compile
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.
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.
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: the dreaded 64-bit compile
Matt- this was for the 32-bit build, so I explicitly did *not* pull the 64-bit stuff.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- Posts: 39
- Joined: Tue Apr 23, 2013 1:30 am
Re: the dreaded 64-bit compile
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.
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.
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: the dreaded 64-bit compile
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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- Posts: 39
- Joined: Tue Apr 23, 2013 1:30 am
Re: the dreaded 64-bit compile
I see. Odd that that wasn't tested better before the release. Is there an internal RunRev test suite?
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: the dreaded 64-bit compile
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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: the dreaded 64-bit compile
@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?
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?
Re: the dreaded 64-bit compile
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
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: the dreaded 64-bit compile
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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: the dreaded 64-bit compile
@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!
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!
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: the dreaded 64-bit compile
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
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
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: the dreaded 64-bit compile
@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.
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.
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: the dreaded 64-bit compile
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).
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).
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: the dreaded 64-bit compile
The magic incantation
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.
Code: Select all
git pull --recurse-submodules origin develop
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev