Remove 32 bit files?

[mcarans]

Is anyone using 32 bit versions of files? If not, I'd suggest removing https://github.com/OoliteProject/oolite ... master/x86 and moving the folders here up to the root: https://github.com/OoliteProject/oolite ... ter/x86_64, simplifying GNUmakefile accordingly. This is something I'm happy to look at.

(I'm also wondering if the same can be done for Windows)

[MrFlibble]

Is anyone using 32 bit versions of files? If not, I'd suggest removing https://github.com/OoliteProject/oolite ... master/x86 and moving the folders here up to the root: https://github.com/OoliteProject/oolite ... ter/x86_64, simplifying GNUmakefile accordingly. This is something I'm happy to look at.

(I'm also wondering if the same can be done for Windows)

Perhaps officially ditching 32 bit should be a 1.92 release step.

Nobody seems to be posting here about 32 bit issues, so one of three things applies. Either it works flawlessly, or it doesn't and they shrug and move on silently, else nobody's using 32 bit. Only the middle case would have any bearing on keeping 32 alive, but sadly it's the hardest to detect.

I imagine quite a few Windows users still have 32 bit and don't know or care, though they will all have the rug pulled out from under them presently when Mickeysoft ditch Win10 support. If MS don't actually hit a kill-switch, a motherload of users will continue without updates for a good while.

I've been messing with Linux-deps in my fork, and bothered to mirror edits in i386. (I simplified how that works, copy script, edit one variable). I should test it still builds and works another day, unless someone gets there first.

[another_commander]

The Windows port has already departed from 32-bit and there is already a note in the downloads section of oolite.space that 1.90 is the last version to have 32-bit support on Windows.

[MrFlibble]

The Windows port has already departed from 32-bit and there is already a note in the downloads section of oolite.space that 1.90 is the last version to have 32-bit support on Windows.

Win32 is about to die in the wild.

Linux 32 is still keeping some hardware out of landfill for a while, possibly more soon.

I've just tried building on LMDE6 i686 in a 32 bit qemu/libvirt VM. I used my fork, and updated the readme there to show how to make it build. Also fixed some sillies in the installer ($HOME was getting expanded in some places in the created wrapper scripts).

It builds. The installer works. It segfaults with no clues just after bringing up a window.

Adding -novsync -nosplash -noshaders -nosound -nodust makes no difference.

ldd shows all required stuff installed.

1.90 runs in the VM.

It'd be cool to get a 32 bit version of 1.91 working on Linux, even if 32 gets dropped soon.

[hiran]

It'd be cool to get a 32 bit version of 1.91 working on Linux, even if 32 gets dropped soon.

Who would really use a 32bit system today? Linux 32bit is not available on today's desktop Linux distributions. Even Raspberries run aarch64.
The effort to maintain such a build is bigger than the time for users having fun with it. I would silently drop it and focus on current systems.

Edit: I seem to forget there are lots of nostalgiathetes here who would love to see Oolite still run on 8bit microprocessors - with full OXP and HDR support?

[Cholmondely]

8bit microprocessors

8bit microprocessors? Codswallop! We want clockwork!!



And... where do I plug in my HOTAS?

[mcarans]

8bit microprocessors? Codswallop! We want clockwork!!

And... where do I plug in my HOTAS?

The Windows port has already departed from 32-bit and there is already a note in the downloads section of oolite.space that 1.90 is the last version to have 32-bit support on Windows.

Win32 is about to die in the wild.

Linux 32 is still keeping some hardware out of landfill for a while, possibly more soon.

I've just tried building on LMDE6 i686 in a 32 bit qemu/libvirt VM. I used my fork, and updated the readme there to show how to make it build. Also fixed some sillies in the installer ($HOME was getting expanded in some places in the created wrapper scripts).

It builds. The installer works. It segfaults with no clues just after bringing up a window.

Adding -novsync -nosplash -noshaders -nosound -nodust makes no difference.

ldd shows all required stuff installed.

1.90 runs in the VM.

It'd be cool to get a 32 bit version of 1.91 working on Linux, even if 32 gets dropped soon.

I think that at this stage trying to restore the 32 bit version is likely to be a lost cause particularly as the segfault gives no clues. Effort would be better spent on other improvements. (For example I wonder if https://mulle-objc.github.io/ which has Foundation support on Windows, Apple and Linux would go part of the way to enabling Oolite to work on newer Apple computers, perhaps solving problem number 3 here: https://github.com/OoliteProject/oolite/issues/360, but to even consider trying it requires simplifying the various makefiles as much as possible first.)

[MrFlibble]

Who would really use a 32bit system today? Linux 32bit is not available on today's desktop Linux distributions. Even Raspberries run aarch64.

Debian? (LMDE?) Arch?

I grant that 32 bit is currently headed for landfill, though in some parts of the world anything that ticks will do. What's the rush to kill it?

I was astonished to find that LMDE6 32 bit was actually very usable. Even in a VM, libreoffice loaded fast, and Oolite 1.90 was slicker than in a 64 bit VM.

Ok. I'm fed up with turning the key. Let it die

[mcarans]

I've made this change in this PR: https://github.com/OoliteProject/oolite/pull/521

[hiran]

I've made this change in this PR: https://github.com/OoliteProject/oolite/pull/521

Nice work. I'm wondering where a test build might be available.

[mcarans]

I've made this change in this PR: https://github.com/OoliteProject/oolite/pull/521

Nice work. I'm wondering where a test build might be available.

Thanks! At the moment, the main Oolite repo doesn't produce working Linux test builds. I can make one for Windows that works (as that is what I installed for my first Oolite install on Windows to test what I did).

I can make a Linux installer that works fine on my machine that has all dependencies including Clang compiled libobjc2 and gnustep-base but it will fail on other machines that don't have these dependencies.

To test this on Linux, you would have to build Oolite from source (and if you wish to use Clang instead of gcc, build libobjc2 and gnustep-base as described here: https://wiki.alioth.net/index.php/Compi ... ead_of_gcc).

Producing Linux test builds should be straightforward once MrFlibble's changes to simplify and fix the Linux build are merged into the main Oolite repository, but in the meantime if you are able, you can build from source on Linux (with or without Clang and the 2 libraries). It might be possible for MrFlibble to pull my changes into his repo to produce a working Linux test build if that were useful - I've only changed Makefile and GNUmakefile and added files.make and flags.make.

[another_commander]

Please be advised that mcarans' pull request on github has been tested under Windows and found to work. So it's a go ahead from my side to merge it.

Once this is merged, Linux 32-bit builds are officially considered abandoned, since all references to 32-bit architectures are being removed from the project's makefiles. Maybe a notice on oolite.space once Linux 32-bit support is dropped would be a good idea.

If anyone has a strong reason for this to not happen, please speak up now.

Current plan is to allow a couple of days for some additional testing and, if no objections occur, merging of the PR will happen this weekend.

[another_commander]

32-bit support for both Windows and Linux has ended. PR merged.

[Lone_Wolf]

Nice, will oolite-linux-dependencies and oolite-windows-dependencies submodule repos also be updated with this change ?

[MrFlibble]

Nice, will oolite-linux-dependencies and oolite-windows-dependencies submodule repos also be updated with this change ?

I've already pulled these changes into my fork, and zapped Linux-deps/x86.

Please folks, test my fork..

If people are happy that it's improved things on Linux, I'll delete the obsolete stuff, 'unbreak' .github/workflows/build-all.yml, and do a PR.