Speaking of compilers being trickier, the arch source build just started failing with an error building gnustep-base that I've not seen before: https://github.com/mcarans/oolite/actio ... 7103273305 - is that one you've come across?
configure: error: Your compiler does not appear to implement the -fconstant-string-class option needed for support of strings. Please check for a more recent version or consider using --enable-nxconstantstring
That build appears to use clang/libobjc2 and archlinux only provides gcc builds of gnustep-base and gnustep-make .
In order to build oolite against clang / libobjc2 three additional package are needed :
libobjc2 (is in aur)
gnustep-make built against libobjc2 with clang
gnustep-base built against the other 2 with clang
The last 2 don't exist atm, how are you providing them and when did you switch the arch source build to clang ?
Speaking of compilers being trickier, the arch source build just started failing with an error building gnustep-base that I've not seen before: https://github.com/mcarans/oolite/actio ... 7103273305 - is that one you've come across?
configure: error: Your compiler does not appear to implement the -fconstant-string-class option needed for support of strings. Please check for a more recent version or consider using --enable-nxconstantstring
That build appears to use clang/libobjc2 and archlinux only provides gcc builds of gnustep-base and gnustep-make .
In order to build oolite against clang / libobjc2 three additional package are needed :
libobjc2 (is in aur)
gnustep-make built against libobjc2 with clang
gnustep-base built against the other 2 with clang
The last 2 don't exist atm, how are you providing them and when did you switch the arch source build to clang ?
All the GitHub Actions Linux builds regardless of distro use clang and build libobjc2, gnustep-make and gnustep-base from source because the GNUstep devs have made some fixes not in the latest stable releases.
Yes, archlinux switched to llvm 22.1.x on march 14 .
I may have time to prepare local packages compiled with clang for gnustep-base & gnustep-make later this week, but until those are ready I can only build oolite with gcc.
What version/commit of gnustep code are you using ?
Who maintains the "official" arch package for oolite? Would they definitely be opposed to the idea of having the package simple wrap the existing script provided on oolite.org? That would allow the app to work as intended by the devs even when installed from the repo. I for one only found out about oolite by browsing the arch repo for games, and I'm sure a lot of other people are going to default to that path.
Re: dependency hell, I'd respectfully disagree with those thinking that self-contained packages are the answer. It works ok for a time when you have a small number of dependencies that you understand fully. But it opens you up to a whole load of issues in the longer term - for example shared configuration for components becomes challenging and obviously there's the bloat. As someone who used to write Java web apps I can tell you that bundling all your dependencies definitely does not solve all your problems! When you spend days tracking down weird bugs caused by multiple versions of the same class existing in memory at the same time, having each app bundle its deps looks a lot less attractive.
The other thing is that in the end it just defers problems. If oolite continues to be developed actively, some day, there will be a compelling argument for bumping one of the dependencies. Maybe because it would improve the software, or maybe because libXYZ.1.0 depends itself on a deprecated OS feature that has now finally been removed. By that point it may have its own updated dependencies, which cause their own problems (obvious if you're lucky, latent and subtle if you're not) and suddenly you have a horribly gnarled mess that needs to be fixed all in one go, and no one wants to tackle it - so it never happens. I've seen a lot of FLOSS projects slowly die that way Personally, I've found that the small, recurrent pain involved in keeping dependencies tolerably up-to-date as you go is far outweighed by the crushing dread of facing down 5 years' worth of updates in one go. But I guess that's a personal preference: you pays your money^H^H^H^H^Htime and takes your choice!
For the avoidance of doubt, I'm not trying to persuade anyone to change the way Oolite is currently managed in this regard. You've got a system that works for you and that's great. I'd just like to throw in my defence of the general concept of the mainstream package management approach for the sake of balancing the discussion
That post is not really relevant for this thread, but it does have some interesting remarks about bundling deps.
A bit of history may be interesting / helpful .
Only packages in archlinux [core], [extra] and [community]* repos are considered official .
In 2018 archlinux devs decided to replace espeak with espeak-ng. This caused espeak and all packages depending on it to be dropped to AUR .
So at that time there was no longer an official archlinux oolite package anymore.
The now unofficial oolite packge in AUR was adopted by SanskritFritz who maintained it until july 2025 when I took over.
As AUR maintainer of oolite I need to follow archlinux package guidelines but have a lot of freedom otherwise .
My personal view of bundled deps is that they should only be used as a last resort.
As far as I can tell oolite on archlinux only uses one external bundled dep : oolite javascript also known as spidermonkey-ff4 .
The github arch source build this thread is about is intended to be used by oolite developers working on oolite sourcecode using archlinux systems.
Such an install has requirements that can't be fulfilled by an archlinux package. A custom script ran as user solves this.
* [community] repo (stopped to exist and) was integrated in [extra] repo when archlinux migrated the repos from svn to git.
AppImage and Flatpak are 'user oriented' packages that come with all their dependencies bundled.
But if you look server-side, containers as lxc or docker made applications transferrable big time. In today's datacenters you cannot miss looking at container operating systems such as Kubernetes.
Having seen all this I do not agree that bundling dependencies has a downside. In contrary it makes managing the dependencies a lot easier. But I agree the issue is not eliminated completely.
Going back to the Java jar-hell: You can isolate problems by using different classloaders, or different JVMs. So placing one jvm plus all it's jars into one container is useful to reduce the number of combinations faced at runtime. Yet it comes at the cost that more code is in memory, which cancels out reuse and caching.
Appimages and flatpak have their uses AND their own problems, containers are similar .
(Especially docker is known to screw up nft/iptables rules set on the host unless you're very careful.)
Keep in mind that archlinux is user centric NOT user-friendly .
While there are people that run server software on archlinux systems succesfull (even in some commercial environments with hundreds of systems) , it's not recommended to do that.
Arch has been a rolling release distro since its inception in 2002 and this means we continually update every package and have no fixed releases or a release schedule.
Days without updates are rare for archlinux users and if there are no updates for several days that usualy means there is a problem with the local system.
Over time there have been plenty of cases where using appimages and flatpaks caused issues that archlinux packages built from source for the same sw didn't have issues..
Typically this was because the archlinux system libs were too new for the bundled deps.
All the GitHub Actions Linux builds regardless of distro use clang and build libobjc2, gnustep-make and gnustep-base from source because the GNUstep devs have made some fixes not in the latest stable releases.
checking whether objc really works... yes
checking if the compiler supports -fconstant-string-class... no
configure: error: Your compiler does not appear to implement the -fconstant-string-class option needed for support of strings. Please check for a more recent version or consider using --enable-nxconstantstring
Yes, archlinux switched to llvm 22.1.x on march 14 .
I may have time to prepare local packages compiled with clang for gnustep-base & gnustep-make later this week, but until those are ready I can only build oolite with gcc.
What version/commit of gnustep code are you using ?
Latest master - there are bug fixes GNUstep devs have made that are not in 1.31.1 (and probably another one coming shortly for llvm 22). Also libobjc2 has a bug fix.
For a rolling release like Arch, providing Oolite as a package works well because dependencies are usually up to date (other than for GNUstep with clang). For other distros, versions of dependencies may be too old.
Personally I wish Linux would standardise on Arch and have a bleeding edge rolling release and a delayed tested rolling release and also focus on one or maybe two desktop environments then app and game developers might be more inclined to port from Windows and Mac instead of giving up because it's too much work to support all the flavours, but this is for another discussion.
Personally, I've found that the small, recurrent pain involved in keeping dependencies tolerably up-to-date as you go is far outweighed by the crushing dread of facing down 5 years' worth of updates in one go. But I guess that's a personal preference: you pays your money^H^H^H^H^Htime and takes your choice!
