github build woes

[MrFlibble]

I've just updated the linux static libraries bundle on my fork, which as far as I can see is otherwise much the same as the 'proper' master. I confess I've simplified the doxygen bit in actions, using the one in ubuntu rather than grabbing ti and building. Seems adequate, builds faster.

The build today failed at the doxygen step and build-linux. The first because github have deprecated actions/upload-file@v3, which was called in by actions/upload-pages-artifact@v2.. so I tweaked the one character required to fix that in the build-all.yml.

Code: Select all

-actions/upload-pages-artifact@v2
+actions/upload-pages-artifact@v3

That fixed the doxygen build.

However, something else seems to have changed in a breaking way. At build-linux (pkg-posix), we see:

Code: Select all

/usr/bin/ld: deps/Linux-deps/x86_64/lib_linker/libSDL.so: undefined reference to `pthread_sigmask@GLIBC_2.32'
/usr/bin/ld: deps/Linux-deps/x86_64/lib_linker/libSDL.so: undefined reference to `stat@GLIBC_2.33'
collect2: error: ld returned 1 exit status
make[5]: *** [/usr/share/GNUstep/Makefiles/Instance/objc.make:79: obj.spk/oolite] Error 1
make[4]: *** [/usr/share/GNUstep/Makefiles/Instance/objc.make:64: internal-objc_program-all_] Error 2
make[3]: *** [/usr/share/GNUstep/Makefiles/Master/rules.make:297: oolite.all.objc-program.variables] Error 2
make[2]: *** [/usr/share/GNUstep/Makefiles/Master/objc.make:36: internal-all] Error 2
make[2]: Leaving directory '/home/runner/work/oolite/oolite/oolite'
make[1]: *** [Makefile:142: deps-release-deployment] Error 2
make[1]: Leaving directory '/home/runner/work/oolite/oolite/oolite'
+ make_rc=2
+ '[' 2 -ne 0 ']'
+ exit 2
make: *** [Makefile:215: pkg-posix] Error 2
Error: Process completed with exit code 2.

Of course that's not the whole log, but I see only warns and notes above.

Anyone "in the know" got a minute to have a proper look please?

https://github.com/OoMrFlibble/oolite/a ... 38628#logs


Problem solved-ish. I commented it out in the lib_linker script, as it wouldn't have been there/done anyway.

Perhaps lib_linker needs updating/reconsidering? Maybe we could use that as a good place to grab all the static bundle of libs? That might help if building on an even older platform with a view to making a flatpak or appimage.

[MrFlibble]

GitHub:

We will soon start the deprecation process for Ubuntu 20.04. While the image is being deprecated, you may experience longer queue times during peak usage hours. Deprecation will begin on 2025-02-01 and the image will be fully unsupported by 2025-04-01.

Which basically means we'll have to either build elsewhere, or accept that backwards compatibility with systems which will still be supported for a few years, will break.

I suppose some horrible workarounds involving a chroot or proot installed older OS (if actions supports that) could be employed to preserve backwards compatibility.

[hiran]

GitHub:

We will soon start the deprecation process for Ubuntu 20.04. While the image is being deprecated, you may experience longer queue times during peak usage hours. Deprecation will begin on 2025-02-01 and the image will be fully unsupported by 2025-04-01.

Which basically means we'll have to either build elsewhere, or accept that backwards compatibility with systems which will still be supported for a few years, will break.

I suppose some horrible workarounds involving a chroot or proot installed older OS (if actions supports that) could be employed to preserve backwards compatibility.

Not sure about the meaning for the community .

For me Oolite does not have to be backward compatible. I have decent hardware with an up to date OS. But Oolite won't run. It never did on Ubuntu 24 LTS.

So my OS is not compatible, I cannot fix it but at the same time it is ok. It could just mean that anorher platform is gone.

[Cholmondely]

Backwards compatibility

For me Oolite does not have to be backward compatible. I have decent hardware with an up-to-date OS. But Oolite won't run. It never did on Ubuntu 24 LTS.

So my OS is not compatible, I cannot fix it but at the same time it is OK. It could just mean that another platform is gone.

It certainly used to matter.

Having spent hours poring over the old threads, one constant theme which comes up time and time again is that many people were using old computers/old versions of operating systems.

Even now, I use a 5 year old AppleMac and stubbornly refuse to update my OS (my updating experiences are miserable. Miserable.). But there are similar statements from Wildeblood (mChat archive: Wildeblood • Mon Feb 17, 2025 10:26 am) and Cody said something similar to me a month or so ago.

I'm willing to accept that it might be different for you Linux types. You all seem to be computer whizz-kids who prang your prams at the drop of a hat (I gaze at Mr Flibble's declarations in a mix of befuddlement, bedazzlement, bewilderment and bemusement).

[Wildeblood]

I gaze at Mr Flibble's declarations in a mix of befuddlement, bedazzlement, bewilderment and bemusement.

It's the begonement that will really get you; when you start sensing begonement, it's time to worry. As ever, a clear statement of the problem would help: what do you seek to make compatible with what?

Should the leading edge version of Oolite be compatible with:-
The most OS versions possible?
The most popular OS on new computers being bought today?
The most common OS globally?

Should the most recent, presumably most feature-rich, version seek to satisfy that desire, or is it sufficient that a version does?

[MrFlibble]

Should the leading edge version of Oolite be compatible with:-

Within the Linux scope of that, I'm aiming for broadest compatibility. Linux is a broad bazaar of platforms and 'current' versions.

Stable (1.90) would ideally in the package managers of major distros, if of course they can be encouraged into finding devs to take it on. For most distros there would be little work to do. The same could be done going forward if we nailed down a 1.92.

Those who want bleeding edge are more likely to make a little extra effort. For example, those with Gentoo are unlikely to have problems building from source, or even making an ebuild file to simplify the task for others.

The majority of those for whom it does not work, are unlikely to bother joining the forums to let us know.

The current state of play on the github 1.90 version binaries: It will work nicely on a very small range of distros. The 1.91 when built by github actions will soon only work on the latest Ubuntu and some contemporaries, leaving the rest behind, even if they are still 'current'. Not so funny when the majority are likely to be among "the rest", using for instance LinuxMint 21.3, which is supported for a few years yet, or the previous version of Ubuntu. The reason for this limitation is largely that nobody has checked the bundled libraries for a while, and github keeps changing the 'current' ubuntu build platform on Actions, so it'll only work where the hosting system is a close relative of the build system. Also of note, the github "Actions" system tends to phase-out build systems long before they diminish in the field as client systems.

We could:

• provide source and instructions (least friendly) We do this.
  [*}a universal installer built on the oldest platform one can muter with bundled libraries (medium friendly) We sort of do this.
  [*}build per platform installers/packages (best)

We don't do this at all, though we might be able to trivially do it for contemporaries of the build host.
The middle option, the universal installer, could equally be an AppImage built on the oldest platform available for broadest compatibility.

For the 'universal' binary of the newer on Github, my fork has refreshed bundled libraries to make it function on a broader range of distros. I just sat down with a couple of VMs and picked the fluff off the Linux dependencies. Building on an older platform would be even more universal. If it is built on the latest platform, no amount of bundled libraries will help. In a couple of months, github actions will force that to be, unless we use an external build host (A small VM could do that, and I can provide if needs must).

Only building a version which will only work on the latest version of the most popular platform might make some sense for e.g. Windows, but it's never likely to be the right way ahead on Linux.

Wow! Has anybody got a ladder? This horse is higher than I'd anticipated.