the dreaded 64-bit compile

[monte]

Is this 64-bit OS X? Nice

[mwieder]

It's hopefully on the way. I'm down to three errors if I ignore all the warnings. I still have to set separate targets for the 32- and 64-bit builds because we're going to need both.

I notice the arm support is all 32-bit and there are some 64-bit arm server processors in the wings, probably for later this year. I'm reluctant to get into that, though, because it's not something I'll be able to test.

[mwieder]

I'm backing off a little bit on the 64-bit compiles.
I can build everything on 32-bit and 64-bit linux now except for the server (problem finding curl.h for some reason that I haven't yet determined), but it occurs to me that we will need to deploy 32-bit standalones from 64-bit systems.
This means two things:

First of all, we're going to need more deployment options in the standalone builder. This gets into the IDE changes, and the team isn't ready for those at this point.

Secondly, it means that the #ifdefs I have in place in the source files and the changes I made to the various makefiles are not generic enough. I can't currently build a 32-bit standalone engine on a 64-bit system. For instance, I'm currently passing "-m32" or "-m64" as a gcc option depending on the OS and I need to override the "-m64" in order to do a 32-bit compile. I've been trying to avoid a whole separate set of makefiles and/or source files for this, but may just have to bite the bullet and do it.

[monte]

Hmm... I'd like to encourage you to keep going. Getting the engines compiling first is definitely the horse and cart in the right order. I see your last commit was a successful OS X build which is awesome. It would be great to get a server build out there given that's starting to become a blocker for server installs... none of the deployment issues to worry about either.

[LCMark]

It is great to see so much progress here

We're going to start integrating the changes needed to make 64-bit compiles work into the main branch (well, what will be the development branch for the next non-maintenance version) and look into starting to push out 64-bit Linux (and hopefully Mac Server builds). It might take a while before they can be considered 'stable', and for the necessary standalone builder changes to get sorted but at least we'll be finally on the (long?) road to 64-bit.

[mwieder]

I'm having the 64-bit binaries return a value for "the machine" and "the processor" that comes from a call to uname. Is there any reason not to do this? It will mean some changes in the docs and possibly some breakage for an application that's currently looking explicitly for "x86". But I think it will be important to be able to differentiate between the 32-bit and 64-bit binaries, specifically in the case of calling external library routines.

Also, a return values of "MacOS" and "win32" for platform don't seem appropriate any more.

Code: Select all

put the machine

results (on linux)
32-bit : i386
64-bit : x86_grep64

Same thing for "put the processor", where before it just hard-coded a return value of "unknown".

[ricochet1k]

I now have the entirety of LiveCode community building on my system. I have pushed all the changes I needed to make here: https: //github. com/ricochet1k/livecode/tree/release-6.0.1. This is also needed: https: //github. com/runrev/livecode-prebuilt/pull/1

I would submit a pull request, but I'm not certain all of the changes should be made in general, such as the libz shuffling (the included libz wasn't working, I had to use the one from my system).

I haven't tested standalone building yet other than Android, which isn't working.

What does "the machine" or "the processor" return on a mobile device? "arm"?

[mwieder]

@Matt- thanks - I missed the prebuilt libraries on runrevmark's fork. But I'm stil getting the same linker problems trying to build the server:

/usr/bin/ld: cannot find -lcurl
/usr/bin/ld: cannot find -lssh2
collect2: error: ld returned 1 exit status

[ricochet1k]

I just found the new prebuilts today. As for the ssh2 and curl, I think they aren't being found because the prebuilt ones are 32-bit? I added /usr/lib to the search path to grab the ones on my system. IIRC, the file was rules/common.linux.makefile, or one of those. It should be in one of the commits in my branch I "linked" above.

[mwieder]

I think they aren't being found because the prebuilt ones are 32-bit?

That's my guess, too. I'm trying not to add external links to the build process, but to fix it instead, but I may have to link my existing libraries in and just make a note of this.

[LCMark]

Okay - so I've spent most of the afternoon on integrating the 64-bit linux changes and am almost done. Unfortunately, due to the various issues between 'master' and 'release-6.0.1' I couldn't just pull in the mwieder's 64-bit branch - so I went through and did things manually. I held off on integrating things that fixed warnings, and just the substantive changes needed to get it working on x64 (I'll integrate the graphics performance changes separately).

At the moment, the Makefiles will build with the default architecture of the compiler since multilib doesn't seem to work so well with gtk on Ubuntu 12.04 (the distro I've been using - I'll need to try another) and there are a few 'hacks' here and there to do the right thing. Since I'm not quite happy with it yet, I've left it as a feature-linux_x64 branch in my (runrevmark/livecode) fork - feel free to take a look.

Btw, I've already pushed the changes to thirdparty and prebuilt into the runrev repo's - there are now 64-bit versions of ssl, crypto and curl alongside the 32-bit ones... This means everything (server and all) should build with x64 too

Should have said - the complete list of dev package dependencies I had to install in a fresh Ubuntu were:

• 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

[ricochet1k]

Using "gcc -dumpmachine" might not be the best idea. On my computers I'm getting x86_64-unknown-linux-gnu, which will try to build as 32 bit with your makefiles. Something like "uname -m" is probably a better idea. Or maybe just checking the start of the machine, not all of it?

Edit: Would it also be worth it to move the PLATFORM var to the top-level Makefile so it doesn't have to be redefined so often?

[LCMark]

They were two things I wasn't particularly happy with (among others).

I did wonder whether 'gcc -dumpmachine' might give different values on different systems for the same processor. Sounds like 'uname -p' would be more appropriate - thanks.

In terms of redefition of PLATFORM - might be better to include the common environment makefile (from rules) at the top of each principal Makefile instead. That way, individual components can still be built from within their folders, rather than always having to run the top-level Makefile.

[ricochet1k]

`uname -p` is "unknown" on my machine, while `uname -m` is "x86_64"

[mwieder]

The -p option is more recent than -m. OSX doesn't support it either. But I find on systems that do support it (linux mint, fedora core) it returns the same thing as -m.