[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Fink
Subject: Re: Which ObjC2.0 features are missing in the latest GCC?
Date: Mon, 25 Nov 2019 18:07:22 +0100

On 25 Nov 2019, at 14:37, Yavor Doganov <address@hidden> wrote:

Gregory Casamento wrote:
On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov <address@hidden> wrote:
The answer is simple: because there's a lot to lose and nothing to

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.


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

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

Lets see what clang-10 supports under Debian10

# llc-10 --version
  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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]