Page 1 of 1
How hard would it be to move Oolite to "modern" Objective-C?
Posted: Mon Sep 22, 2025 8:12 pm
by mcarans
On Ubuntu, I have Oolite working with Clang and the Objective-C 1.9 ABI. A GNUstep developer, David Chisnall, asked:
"What syntax does it use that isn't supported on newer ABIs? As far as I remember, the only thing is @defs, which is pretty easy to work around. A quick search of the OOlite source code doesn't find it anywhere."
https://github.com/gnustep/libobjc2/iss ... 3317719251
If Oolite were able to work on Objective-C 2, it would simplify the build environment as the MSYS2 MinGW64 packages are set up for Clang with Objective-C 2 by default. It would probably also make it easier if Oolite were ever to be ported to other platforms like new Macs.
What known obstacles are there to getting Oolite to build with Objective-C 2?
Re: How hard would it be to move Oolite to Objective-C 2?
Posted: Mon Sep 22, 2025 9:41 pm
by Commander_X
From what I could gather, Objective-C 2 is "fully compatible with FSF's GCC Objective-C ABI", and it seems to bring its support only for Clang.
In your mingw64 build, you already provide GCC's Objective-C runtime (libobjc-4.dll), which should be 2.0+ compatible.
Re: How hard would it be to move Oolite to "modern" Objective-C?
Posted: Mon Sep 22, 2025 10:10 pm
by mcarans
Commander_X wrote: ↑Mon Sep 22, 2025 9:41 pm
From what I could gather, Objective-C 2 is "fully compatible with FSF's GCC Objective-C ABI", and it seems to bring its support only for Clang.
In your mingw64 build, you already provide GCC's Objective-C runtime (libobjc-4.dll), which should be 2.0+ compatible.
From reading the
Wikipedia article on Objective-C, I realise that my question should use the term "modern Objective-C" rather than Objective-C 2. It's a bit confusing but as you say, looks like
gcc supports most or all of Objective-C 2. However,
modern Objective-C is only supported by Clang.
I think the MSYS2 MinGW64 packages are set up with a 2.2 ABI by default based on the fact that this is what the GNUstep developers use in their
GitHub Actions test. So my question I suppose boils down to: what obstacles (if any) such as incompatible language constructs are there to building Oolite with Clang, libobjc2 and the 2.2 ABI (which would remove the need to build the GNUstep-make and GNUstep-base packages from source on MinGW64)?
Re: How hard would it be to move Oolite to "modern" Objective-C?
Posted: Wed Sep 24, 2025 2:35 pm
by Lone_Wolf
It would likely break compatibility with gcc making llvm/clang support a hard dependency for oolite.
Another problem is that while gcc has one implementation llvm/clang doesn't .
On linux AMD maintains 2 versions of llvm/clang : AOCC and RocM-llvm . Both differ substantially from upstream.
You are talking about building with msys2 mingw clang .
Are you aware that there's also msys2 clang, cygwin clang and visual studio clang ?
That makes 4 clang implementations on windows that are not fully compatible with upstream and definitely not compatible with eachother .
Another thing to keep in mind : newer versions of gcc & llvm/clang often break things for older code but the amount of breakage in llvm/clang is much worse
I have been maintaining an llvm trunk build for years because of mesa needs llvm..
Archlinux builds mesa against gcc , but severasl parts of mesa require things that are only found in llvm/clang .
Mesa can also be built with MSVC. The number of bugs in mesa related to llvm/clang are much higher then those related to gcc / msvc .
Re: How hard would it be to move Oolite to "modern" Objective-C?
Posted: Tue Sep 30, 2025 7:34 pm
by mcarans
Lone_Wolf wrote: ↑Wed Sep 24, 2025 2:35 pm
It would likely break compatibility with gcc making llvm/clang support a hard dependency for oolite.
Another problem is that while gcc has one implementation llvm/clang doesn't .
On linux AMD maintains 2 versions of llvm/clang : AOCC and RocM-llvm . Both differ substantially from upstream.
You are talking about building with msys2 mingw clang .
Are you aware that there's also msys2 clang, cygwin clang and visual studio clang ?
That makes 4 clang implementations on windows that are not fully compatible with upstream and definitely not compatible with eachother .
Another thing to keep in mind : newer versions of gcc & llvm/clang often break things for older code but the amount of breakage in llvm/clang is much worse
I have been maintaining an llvm trunk build for years because of mesa needs llvm..
Archlinux builds mesa against gcc , but severasl parts of mesa require things that are only found in llvm/clang .
Mesa can also be built with MSVC. The number of bugs in mesa related to llvm/clang are much higher then those related to gcc / msvc .
I would aim for simply building using MSYS2 MingGW64 default Clang install without changing the Oolite source code (like I've done on Ubuntu with Clang and ABI 1.9). According to GNUstep developers, it should
work without changes in ABI 2.2, so in theory it should just be a case of installing the default libraries and then building Oolite (on MSYS2) while on Linux it would involve rebuilding GNUstep base using Clang and ABI 2.2 then building Oolite.
Re: How hard would it be to move Oolite to "modern" Objective-C?
Posted: Wed Oct 01, 2025 11:55 am
by Lone_Wolf
That suggests it may be possible to build just libobjc2 with clang , then build gnustep-base with another compiler .
On archlinux I can look into building libobjc2 against clang 21 , then gnustep-base against libobjc2 with gcc 15.1 .
If succesfull I then can check if oolite can use that.
Simplified it would be like replacing the gcc-objc runtime with the libobjc2 runtime without making other changes.
Do you think that's a good idea ?
Re: How hard would it be to move Oolite to "modern" Objective-C?
Posted: Thu Oct 02, 2025 2:16 am
by mcarans
Lone_Wolf wrote: ↑Wed Oct 01, 2025 11:55 am
That suggests it may be possible to build just libobjc2 with clang , then build gnustep-base with another compiler .
On archlinux I can look into building libobjc2 against clang 21 , then gnustep-base against libobjc2 with gcc 15.1 .
If succesfull I then can check if oolite can use that.
Simplified it would be like replacing the gcc-objc runtime with the libobjc2 runtime without making other changes.
Do you think that's a good idea ?
I'm not sure. As far as I know, gnustep-make has to be set up with either gnu for gcc or ng for clang for the library combo and this then feeds through into how gnustep-base gets built. See
https://github.com/mcarans/oolite_mingw ... GBUILD#L25. You can see setups for gcc, clang ABI 1.9 and clang ABI 2.2 here:
https://github.com/mcarans/libs-base/bl ... in.yml#L87
You could give it a try or ask the GNUstep devs.
Re: How hard would it be to move Oolite to "modern" Objective-C?
Posted: Thu Oct 02, 2025 8:34 am
by Lone_Wolf
gnustep-make does appear to need to be built with clang, will try to test this weekend.
Re: How hard would it be to move Oolite to "modern" Objective-C?
Posted: Sat Oct 11, 2025 4:38 pm
by Lone_Wolf
It turns out there is already a
libobj2 package in AUR.
Although it builds it doesn't comply with archlinux cmake packaging guidelines and has a big issue :
Code: Select all
libobjc2: /usr/lib/libobjc.so exists in filesystem (owned by gcc-libs)
gcc-libs is used by hundreds of archlinux packages and also a component of the archlinux base meta-package that needs to be present on ALL archlinux systems.
As it is now the package can not even be installed on archlinux and likely violates the aur submission guidelines.
I've left a comment on the aur package page, maybe the maintainer will adjust the package.
For now I won't continue with libobjc2 .
Re: How hard would it be to move Oolite to "modern" Objective-C?
Posted: Tue Oct 14, 2025 10:08 pm
by Lone_Wolf
The maintainer of aur libobjc2 has adjusted the package and it's now in good shape,
Next step is to try to use it for a custom gnustep-make .
Re: How hard would it be to move Oolite to "modern" Objective-C?
Posted: Sun Dec 21, 2025 6:51 pm
by Lone_Wolf
Building gnustep-make with clang against the libobjc2 aur package gave an issue that was
solved with help of archlinux forum users .
Now I have to adjust the name of the package and make sure whether it can coexist with the repo gnustep-make or needs to conflict with it.
Once that's been done I can continue with gnustep-base .