|Subject:||Re: Which ObjC2.0 features are missing in the latest GCC?|
|Date:||Mon, 25 Nov 2019 18:07:22 +0100|
I can tell you exactly why. When I tried out GNUstep for the first time to port my OS X apps to Debian, I simply did "apt-get install gnustep" and wanted to compile my code and nothing really worked.
Then it took me several weeks to figure out how to get a working toolchain with libobjc2 and ARC support which my code required. And I am not a newbie. I write code on MacOS since 1994 and Linux since like 1992. The major roadblocks where:
a) the tools which come with Debian where totally useless as it did not support modern Objc2 features which my ported code was using already. And it took a while to even figure that out.
b) the build process is not well documented. You find all kinds of build info out there in the net out of which most are totally outdated and don't work anymore. (this has become a bit better since).
c) there where some bugs, especially in the linking part which where totally throwing you off the rails and where giving very puzzling information.
d) if you don't pay attention, the old runtime libobjc which comes with gcc gets into your way. And the package is named libobjc4. So go figure that libobjc2 is actually newer...
I can assure you that people who are used to MacOS X and Xcode , 99% of it will run away. They will simply claim GnuStep is not a mature project.
If you read through my readme https://github.com/andreasfink/ulib/blob/master/doc/README-Debian9-stretch.txt you will see how many things can go wrong.
Part of the problem was that Debian 9 was packaging clang 3.8 which is quire old these days and was lacking some stuff as well.
Recent Debian 10 however fixed this and adding clang from the llvm repository to get a newer version is kind of not a big issue. These days you need clang8 or newer if you don't want to run into some nasty bugs and use a prebuilt package.
The linker was one of the biggest problem. Easy to fix but very difficult to figure.
I also tried other options beforehand. Namely Cocotron. The problem with that was that its built for crosscompiling from a Mac. Recent upgrades from Xcode basically broke that and I think the folks who work on that are mainly focused to get it run well on Windows and don't care so much about Linux. Also there's not much happening with Cocotron these days. Hence I dropped using it and use GNUStep for all my ObjC code under Linux these days. And for me its performing very well, once I had working packages.
I'm not aware of any other GNU package written in ObjC (or even any other compiled language besides C or C++).
I think it boils down to the question if we want to keep GNUStep as a clone of NextStep (before Apple took over) or if we want it to be useable for porting software from OSX to Unix.
For me the answer is clear.
As far as all the other platforms go which might not be supported by clang and are supported by gcc:
Can we get a bit more concrete and list all Debian supported platforms who have prebuilt GNUStep packages today and who do not have clang support?
And I mean platforms who will have long term support (not like i386 or Tile or something which is about to be dropped).
As of the Stretch release, the official ports are:
Lets see what clang-10 supports under Debian10
# llc-10 --version
LLVM version 10.0.0
Default target: x86_64-pc-linux-gnu
Host CPU: znver1
aarch64 - AArch64 (little endian)
aarch64_32 - AArch64 (little endian ILP32)
aarch64_be - AArch64 (big endian)
amdgcn - AMD GCN GPUs
arm - ARM
arm64 - ARM64 (little endian)
arm64_32 - ARM64 (little endian ILP32)
armeb - ARM (big endian)
avr - Atmel AVR Microcontroller
bpf - BPF (host endian)
bpfeb - BPF (big endian)
bpfel - BPF (little endian)
hexagon - Hexagon
lanai - Lanai
mips - MIPS (32-bit big endian)
mips64 - MIPS (64-bit big endian)
mips64el - MIPS (64-bit little endian)
mipsel - MIPS (32-bit little endian)
msp430 - MSP430 [experimental]
nvptx - NVIDIA PTX 32-bit
nvptx64 - NVIDIA PTX 64-bit
ppc32 - PowerPC 32
ppc64 - PowerPC 64
ppc64le - PowerPC 64 LE
r600 - AMD GPUs HD2XXX-HD6XXX
riscv32 - 32-bit RISC-V
riscv64 - 64-bit RISC-V
sparc - Sparc
sparcel - Sparc LE
sparcv9 - Sparc V9
systemz - SystemZ
thumb - Thumb
thumbeb - Thumb (big endian)
wasm32 - WebAssembly 32-bit
wasm64 - WebAssembly 64-bit
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
xcore - XCore
So the real question is: Are we ok to drop support for s390x in exchange of support of Objc2.0 support and much cleaner code in libobjc2 ?
Personally I don't know anyone who even has a s390x so I can't even tell if it makes any sense to have Gnustep on such a platform.
|[Prev in Thread]||Current Thread||[Next in Thread]|