How hard would it be to move Oolite to "modern" Objective-C?

[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?

[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.

[mcarans]

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)?

[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 .

[mcarans]

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.

[Lone_Wolf]

The GNUstep Objective-C runtime was designed as a drop-in replacement for the GCC runtime.

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 ?

[mcarans]

The GNUstep Objective-C runtime was designed as a drop-in replacement for the GCC runtime.

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.

[Lone_Wolf]

gnustep-make does appear to need to be built with clang, will try to test this weekend.

[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 .

[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 .

[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 .