the dreaded 64-bit compile

[mwieder]

Hmm... once you register it won't show that again

That's exactly why I'm stopping at this point.

or are you taking an ideological stand against it?

Yeah.
I can easily fork the code and create an engine that doesn't require this, but that seems somehow... wrong.
I do think new users should be *encouraged* to register, for a number of reasons, but forcing the issue isn't the way to go.
This should probably be a topic on its own, although I know it's getting some heavy discussion on the lists right now.

[monte]

That's exactly why I'm stopping at this point.

So we have a choice between your contributions and the forced login?

I can easily fork the code and create an engine that doesn't require this, but that seems somehow... wrong.
I do think new users should be *encouraged* to register, for a number of reasons, but forcing the issue isn't the way to go.
This should probably be a topic on its own, although I know it's getting some heavy discussion on the lists right now.

Perhaps we can continue to discuss it under the startupstack.cpp topic? I guess if you are taking an ideological stand then it is right to fork it but it's going to be a hassle if you want to also contribute to the engine... hell even changes to config files are causing me hassles... and all the files Xcode seems to want to change all the time...

I guess your repo could contain an extra develop and master branch: master/nologin and develop/nologin and you could merge RunRev's changes into those in order to both keep it up to date and keep it out of the way for contributions. Although you would still need to branch anything you want to contribute of master or develop then test there and probably wait for RunRev to pull it in order for you to pull it back down and merge with your nologin branches... headache I think...

[mwieder]

Perhaps we can continue to discuss it under the startupstack.cpp topic?

Any further discussion of the startup process continued to that thread.
But to the point here, no, I shouldn't have said I'm stopping. What I meant was that I'm in a holding position waiting on further word from the mothership because I can't do more testing without logging in and if I log in I won't see the startup issue and I want to stay in that state until this is resolved. I'll push my changes if they end up working.

[monte]

hmm.. I guess that startup stack writes something somewhere. What if you branch from your changes, remove the startup stack, test. Then you should be able to checkout the head of your current branch and see the startup stack again because it never had a chance to write out it's thing...

[mwieder]

Interesting idea, but my guess is that the license file gets written somewhere outside the git repository area, maybe into my user folder. Just branching won't deal with that.

[monte]

yeah, what I mean is if the stack is bypassed it's not writing the data

[mwieder]

Ah. Right you are. I'll give this a try.

[monte]

unless it's the engine that writes it ... you might want to follow the yellow brick road from the beginning

[LCMark]

It sounds like this is a first step towards 64-bitness on Linux, so it will be worth sending a pull request so we can integrate the initial set of changes. However, there is a lot more to this than just getting the engine to compile...

The externals all have 'pre-canned' configs for the third-party libraries they depend on (in particular, libiodbc, libmysql and libpq) these will need to be checked to ensure that they are suitable for 64-bit.

The engine itself might well not be 64-bit clean in some places - although the best way to find this out is (I guess) to get a build out there for people to start playing with.

We need to organize a suitable build platform for 64-bit. For 32-bit we use Ubuntu 6.06 simply because it builds binaries that work on pretty much all 32-bit linux distros (its old enough to!). For 64-bit we need to find a similarly compatible base. [ At some point I want to see the Linux builds move to using the Linux Standards Base SDK, which should guarantee a good level of cross-distribution compatibility - this would solve the issue for 32-bit and 64-bit ].

We need to sort out pre-canned libraries for curl and openssl, otherwise you get into all sorts of compatibility issues (wrong .so versions and such) with both server and desktop.

Most 'blocking' however, is that the internal deploy code only handles ELF32 at the moment - meaning that 64-bit Linux standalones cannot be built.

[ By the way guys, do try and keep these forums about Engine Contributions - i.e. contributions to the engine source base that you are trying to make or are interested in making - discussion about things that aren't directly related to this (like activation policy, for example) don't really belong here ].

[LCMark]

Actually it seems build platform is easy enough - we'll just use Ubuntu 6.06 64-bit - that means that both 64-bit and 32-bit versions should work on the same range of versions

I'll see if we can schedule some internal engineering time to sort out the build related stuff (precanned libraries, for example) and the deploy mechanism - it would be good to see 64-bit LiveCode on Linux out in the wild for testing at some point in the near future.

By the way, Mark, I'm particularly interested in the 'devel' packages you had to install to get it to compile on Mint - if you could construct a definitive list and put it in the pull-request then I'll make sure the 'headers/linux' section is updated correctly so others don't have to go digging around in their package repos for such things thus meaning Linux should build out of the box on most distros.

[monte]

Well... lots of headaches trying to get it to compile on Ubuntu 12.10.... libcurl just won't play nicely for some reason (hundreds of undefined references)... might just download 6.06 one day... I had to install libfontconfig1-dev libfreetype6-dev libxrender-dev libxft-dev libxinerama-dev livxv-dev libxcursor-dev libcurl3-dev

Each one got me a bit further ... but libcurl won't play ball...

[LCMark]

libcurl is only used by server - we need to provide this as a precompiled blob (for versioning reasons) and missed that out of the initial release but this is slated for 6.0.1.

To just build the desktop components on linux you can use (for debug mode, release mode just change debug to release):

Code: Select all

MODE=debug make development

[mwieder]

I'll submit a pull request tomorrow. I need to get back to my 32-bit system and make sure it still compiles and runs there after the changes.

I've also got a second pull request that takes care of eliminating may of the warnings that come up in the compile.

[mwieder]

Oh... and I'm compiling on a 64-bit linux mint 14 and a 32-bit Fedora Core 16.

[monte]

Hmm... mwieder is running make all and so am I. He's obviously not hitting the libcurl issue so I'm wondering what the differences might be there. What are the versioning issues? It would be nice if the third party libraries could be integrated at their current release versions... Oh... and it appears I had neglected to check to see if anything was in _build.. engine, installer and standalone are all there and after copying Toolset in engine works fine.