github arch source build fails

[Lone_Wolf]

Note : continuation of viewtopic.php?p=304418#p304418 in new thread

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?

Code: Select all

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 ?

[mcarans]

Note : continuation of viewtopic.php?p=304418#p304418 in new thread

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?

Code: Select all

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.

I haven't changed anything in the Arch build. For example, this build from 2 days ago succeeded: https://github.com/OoliteProject/oolite ... 7062940797. In the logs of that successful build, you can see:

Code: Select all

:: Retrieving packages...
 clang-21.1.8-1-x86_64 downloading...
 llvm-libs-21.1.8-1-x86_64 downloading...
 compiler-rt-21.1.8-2-x86_64 downloading...
 libedit-20251016_3.1-1-x86_64 downloading...
...
checking whether objc really works... yes
checking if the compiler supports -fconstant-string-class... yes

This is what has changed:

Code: Select all

:: Retrieving packages...
 clang-22.1.1-1-x86_64 downloading...
 llvm-libs-22.1.1-1-x86_64 downloading...
 compiler-rt-22.1.1-1-x86_64 downloading...
 libedit-20251016_3.1-1-x86_64 downloading...

clang has gone up a major version. I have asked the GNUstep devs if they have seen this error: https://github.com/gnustep/libs-base/issues/589

[Lone_Wolf]

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 ?

[Cholmondely]

Came across this... unsure if it is relevant (it is talking about "arch packages"):

So, just tossing a few more cents into the pile:

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

[Lone_Wolf]

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.

[hiran]

Bundled dependencies are bad?

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.

[Lone_Wolf]

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.

[Lone_Wolf]

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.

I haven't changed anything in the Arch build. For example, this build from 2 days ago succeeded: https://github.com/OoliteProject/oolite ... 7062940797. In the logs of that successful build, you can see:

Code: Select all

:: Retrieving packages...
 clang-21.1.8-1-x86_64 downloading...
 llvm-libs-21.1.8-1-x86_64 downloading...
 compiler-rt-21.1.8-2-x86_64 downloading...
 libedit-20251016_3.1-1-x86_64 downloading...
...
checking whether objc really works... yes
checking if the compiler supports -fconstant-string-class... yes

This is what has changed:

Code: Select all

:: Retrieving packages...
 clang-22.1.1-1-x86_64 downloading...
 llvm-libs-22.1.1-1-x86_64 downloading...
 compiler-rt-22.1.1-1-x86_64 downloading...
 libedit-20251016_3.1-1-x86_64 downloading...

clang has gone up a major version. I have asked the GNUstep devs if they have seen this error: https://github.com/gnustep/libs-base/issues/589

The error also appears when building gnustep-base 1.31.1 with clang 21.1.1 .

Code: Select all

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

[mcarans]

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.

[hiran]

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.

Linus created an OS kernel and called that Linux. It is standardized as much as you just need one version number to know what exactly it is.
Unfortunately an OS consists of a lot more than just the kernel. These are the Linux distributions. You wish there were a standard? Then focus on the most popular Linux distribution and go. Having to support so many flavors is a self-inflicted burden that usually stems from not taking a decision.

I focused on one for ease of mind. It means it should be easy to use but also easy to support. Additional investigations left and right of the mainstream look like a waste of time for me.

[Lone_Wolf]

@Mcarans :
Atleast 1 package (shiboken6) still depends on llvm/clang 21 , so archlinux has llvm21 , clang21 etc packages .

Have you tried building with them ?

[mcarans]

@Mcarans :
Atleast 1 package (shiboken6) still depends on llvm/clang 21 , so archlinux has llvm21 , clang21 etc packages .

Have you tried building with them ?

I'm not sure how to make the build use the clang21 if the default on Arch is clang22 - miight require some hackery like a symbolic link or something.

I had intended to wait to see what the GNUstep devs say about it but they have so far been silent (and I even posted on the GNUstep mailing list: https://lists.gnu.org/archive/html/disc ... 00034.html).

[Lone_Wolf]

I'm not sure how to make the build use the clang21 if the default on Arch is clang22 - miight require some hackery like a symbolic link or something.

No symlinks needed.
In the script that you use to install archlinux deps just replace clang with clang21 .

I can't remember how to view the github workflow scripts you use, so can't give more detailed help for now.

[mcarans]

I'm not sure how to make the build use the clang21 if the default on Arch is clang22 - miight require some hackery like a symbolic link or something.

No symlinks needed.
In the script that you use to install archlinux deps just replace clang with clang21 .

I can't remember how to view the github workflow scripts you use, so can't give more detailed help for now.

I think I'd need to do something like this just for Arch:

Code: Select all

export CC=clang-21
export CXX=clang++-21