the dreaded 64-bit compile

[mwieder]

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.

Yeah, exactly the sort of thing we've been trying to avoid.

[LCMark]

Sorry I misread what you had written (-p had occured to me early)... I'll check tomorrow, but I think I saw something other than a 'standard' arch when I ran uname -m on one of my VMs so maybe that isn't as stable as we'd like either... Could be that checking the prefix of whatever command is settled on might still be needed

[mwieder]

Just for the record, I'm also having trouble compiling 32-bit executables on a 64-bit system. The 32-bit dev system isn't installed by default, so there'll be an extra step involved. And the standalone builder will have to be modified, of course, to allow for 32- and/or 64-bit deployments.

[mwieder]

@runrevmark - I'd rather you didn't make the changes manually. I already went out of my way to rebase the commits so that Matt's changes would get integrated properly for attribution. The 6.0.1 mix-in was necessary because Ian fixed a bug that was preventing successful compilation. If you'd like, I can create a separate branch and cherry-pick the changes for a cleaner merge.

[ricochet1k]

I'd have to agree with mwieder. It's not hard for me to edit commits if they aren't exactly correct, such as the "make clean" commit. All you have to do is comment on them.

I do know that you have some better solutions than I came up with, and in those cases I don't mind.

@mwieder: If you are going to be doing that many changes, I highly recommend learning how to use the 'git rebase -i' command. It will save you a lot of time, and is quite powerful. It will automatically squash commits together (if you tell it to), allow you to delete/rename commits, etc.

[mwieder]

@Matt - yes, thanks - I've been playing around with the "rebase -i" command lately. I'm still finding it a scary thing, but I make backups before committing (hah!) myself too deeply.

[monte]

rebasing after you've pushed publicly is usually a big no-no because if someone has branched from your existing commits they will be left hanging...

I'm not really sure why a merge wouldn't have been possible but in the case it wasn't then cherrypick probably would work

[mwieder]

@Monte - yes I wouldn't think of trying to rebase the pushed stuff. I was thinking more of creating a new branch, then cherry-picking the commits for that branch. I did something similar on another project last week, and while it was a matter of a lot of experimentation, it finally got to the desired goal.

[monte]

There's also octopus merge that I haven't played with that allows you to specify multiple commits to merge into head which is I guess equivalent to cherry pick... I really don't know how git handles backporting but apparently you can backport a commit from a develop branch onto a release branch for a bugfix or something with cherry pick... But I don't think this situation was that complicated. All your work should have had ancestors in develop so branching develop and merging your work should have been straightforward.

[LCMark]

@ricochet1k @mwieder: The manual integration I did wasn't meant as any disrespect to you guys - just a mixture of expediency and inexperience with git (I'm learning fast though!). I'm happy to have another attempt at merging from your branches - i'll experiment with cherry-picking commits if necessary; I'd forgotten that was possible. It will also give me a chance to revisit a couple of things discussed earlier as well.

[LCMark]

Okay - redid the integration today - after a bit of git magic I pulled in both the '64-bit' branch from mwieder and the 'fix-makefiles' branch from ricochet1k... Then merged in my changes on top of those - full details are in the comments on the 64-bit branch pull request. Additionally, I've made and committed some changes to the deploy command (the low-level bit of standalone building) for ELF64 and that seems to work.

The branch with all these changes is currently sitting in runrevmark/livecode as 'feature-linux_x64_2' - I'll pull it into the main livecode repo as a feature branch in due course.

[mwieder]

@runrevmark- so is your intention now to have two separate code branches for the 32-bit and 64-bit sources? I had gone out of my way to make agnostic changes, and I find that after pulling the feature-linux_x64_2 branch from your repository I can no longer compile on my 32-bit system.

Code: Select all

"../../rules/archive.linux.makefile:6: *** recipe commences before first target.  Stop."

[LCMark]

Hmmm - it should work - it did on my 32bit vm earlier (Ubuntu 6.06). The error suggests the ARCH variable isn't being setup correctly... This is configured in rules/environment.linux.makefile.

[LCMark]

Just a thought : did you checkout the feature-linux_x64 branches in the thirdparty / prebuilt sub modules. I just realised they have a different name from the branch in my fork (they are in the runrev repos).

[mwieder]

Something's weird here.
In order to do a clean build I cloned the runrev repository anew into a new read-only directory with "clone --recursive https://github/runrev/livecode".
Doing a "git log" shows the last commit as "Update submodules" from 30 April.
Git status shows nothing out of the ordinary.

And doing a "make all" results in
"./src/ide.cpp:405:29: fatal error: hashedstrings.cpp: No such file or directory"