Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

On 25 Nov 2019, at 14:37, Yavor Doganov <yavor@gnu.org> wrote:

Gregory Casamento wrote:

On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov <yavor@gnu.org> wrote:

The answer is simple: because there's a lot to lose and nothing to
gain.

This is patently incorrect.  The gain is time and compatibility with
the latest code base.  I laid out the advantages and disadvantages
of this in my previous posting.

There are no advantages for the current GNUstep packages in Debian
which is the main point I was trying to make.  I don't dispute the
fact that dropping support for GCC will simplify things a lot for
you.  At certain cost, of course, which you consider negligible.

* More Applications, more applications means more end users (sort of
chicken and egg thing)

That's purely hypothetical to the extent of being mere speculation.
GNUstep supports Clang and David's runtime for quite some time now,
why there are no more applications?  Why existing GNUstep applications
have not been updated to take advantage of the new features?

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.

What's to lose:
* Possibly a political issue with the FSF, but there are other projects
which depend on languages not implemented by GCC.

I'm not aware of any GNU package written in a compiled language that
cannot be built with GCC.

I'm not aware of any other GNU package written in ObjC (or even any other compiled language besides C or C++).

I don't know what you mean by "political issue" but such a drastic
change should be discussed with the GNU Project of which GNUstep is
still part of.  It is wrong to decide it with a vote that doesn't even
specify simple things like who is eligible to vote and based on what
majority the decision is going to be taken.  As a GNU maintainer you
should know these things.

* Support for older platforms which ONLY support gcc.

RISC-V is the newest GNU/Linux architecture and it's not yet supported
by Clang.

Wrong

https://riscv.org/2019/10/llvm-clang-risc-v-now-supports-lto-michael-larabel-phoronix/

So, I apologize if I don't agree with the "nothing to gain" opinion.

You are free to disagree.  But as it often happens with real life, the
loss may become obvious only post factum...  You could be left only
with the "gain" which may not look like a big gain then.  It could
even look more like you have shot yourself in the foot.

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

(https://en.wikipedia.org/wiki/Debian#Architecture_ports)

As of the Stretch release, the official ports are:^[157]

• amd64: x86-64 architecture with 64-bit userland and supporting 32-bit software
• arm64: ARMv8-A architecture^[158]
• armel: Little-endian ARM architecture (ARMv4T instruction set)^[159] on various embedded systems (embedded application binary interface(EABI))
• armhf: ARM hard-float architecture (ARMv7 instruction set) requiring hardware with a floating-point unit
• i386: IA-32 architecture with 32-bit userland, compatible with x86-64 machines^[153]
• mips: Big-endian MIPS architecture
• mips64el: Little-endian 64 bit MIPS
• mipsel: Little-endian MIPS
• ppc64el: Little-endian PowerPC architecture supporting POWER7+ and POWER8 CPUs^[158]
• s390x: z/Architecture with 64-bit userland, intended to replace s390^[160]

Lets see what clang-10 supports under Debian10

# llc-10 --version

LLVM (http://llvm.org/):

  LLVM version 10.0.0

  Optimized build.

  Default target: x86_64-pc-linux-gnu

  Host CPU: znver1

  Registered Targets:

    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.