Mainly Windows support and some signature differences between Apple's runtime (private APIs etc). The libobjc2 github repository keeps track of that in the issues segment.
On February 10, 2022 2:37:55 PM GMT+01:00, Andreas Fink <[email protected]> wrote: >What are the real issues of the runtime on other platforms? >I might have a personal interest to do some work on some platforms. > >Gregory Casamento wrote on 10.02.22 03:31: >> Riccardo, >> >> I don't believe that GNUstep should hold back features to remain >> compatible with any given compiler. Not implementing features that >> are widely used (not even particularly "modern" ones) because the less >> capable compiler (in this case the latest GCC) lacks support is not >> a healthy direction. >> >> Like you, I believe in choice. I think that GNUstep should remain >> compatible with GCC so long as GCC is able to keep up with the >> features needed by the project. >> >> It's really simple math. We are a team of limited man-power and, >> currently, there is no one on the time who has the time to do what >> needs to be done to implement the following in GCC: >> >> 1) Support for ARC properties (weak, strong, etc) >> 2) Syntactic sugar as I have specified in recent discussions >> 3) Internal compiler support for ARC (i.e. use the features in #1 to >> drive memory management) >> 4) Runtime changes to support the above >> >> In LLVM/clang the above features already exist. What is missing is: >> >> 1) The ability of the runtime to work on a number of different >> platforms: (Windows, etc) >> (if you can think of anything else that's missing, I'm sure you can >> think of something) >> >> Who is going to write this code, you? (you already say your day job is >> taking over) Mine is as well very taxing. So the question remains, >> which one of the very few of us is going to take on these tasks. The >> path to get clang working is likely much shorter than GCC. >> >> On Wed, Feb 9, 2022 at 6:56 PM Riccardo Mottola >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hi, >> >> sorry for being a little bit absent, day-job is overtaking, I skipped >> the meeting and had no energy to reply. Also, the words chosen >> irritated me and spoke to you guys separately. >> Let me start with a reply on the facts given which here are then >> mixed >> with judgments which are personal of you and some others. So I just >> chime in writing the other side of the medal. >> Also, as stated further in your newer thread "Clang migration" is >> misleading, because the real goal is better ObjC-2 support, which can >> be achieved in different ways. >> >> >> I ask again, who is going to have the time to do this? >> >> >> > 1) GCC lacks support for many memory management features that are >> > commonly >> > used today >> > 2) GCC's objective-c support is lagging behind and doesn't include >> > support >> > for @[], @{}, @autorelease, etc etc etc >> > 3) Lack of bug fixes in GCC's implementation of ObjC >> > 4) GCC team does not consider ObjC release critical and will and HAS >> > released with broken support for building ObjC targets. >> > All of these things are UNACCEPTABLE >> >> The GCC team has improved a lot support and you cite very old things >> that happened years ago. >> >> >> Okay, that's fine. I don't see it in the list above though. The fact >> remains that no one on the GCC team is willing or able to take the >> time to implement a single feature listed in either this list or the >> one above. >> >> >> Amazingly, the last several major releases >> of GCC up to gcc 11 have no issues. So while "legacy" the GCC >> setup is >> amazingly stable on all architectures I can test on (and I have many >> machines!). AlLso those bugs you cite do not show up >> Furthermore those "modern features" do not significantly limit >> development and do not (almost?) impede using then in any >> applications, so the issue is mostly limited to "core". >> >> >> Given that most of these modern features came out in 2006, I think >> it's time we stopped calling them "modern". Also, when you have a >> codebase that has been written within the last 16 years that uses >> these features, it is a major impediment to have to re-engineer your >> code to use an ancient version of Objective-C. The effort I am >> working on NOW in my day job is having to go through this very thing, >> and it's ridiculous in the extreme that this should have to be done. >> >> I would scale them in as inconveniences, maybe serious, but not >> unacceptable. >> >> >> They are more than inconveniences. >> >> >> GCC has its runtime, so its build system tests both together! >> >> >> So what? To most developers who want useful software and just want >> their stuff to work this is meaningless. >> >> > 1) Currently, libobjc2 does not support some architectures and also >> > does >> > not build easily on Windows under MSYS2. While some older >> > architectures >> > are, perhaps, not as important, building on Windows under MSYS2 is >> > critical. >> >> The build setup of GCC is very consistent; the support is very vast >> and the runtime is essentially in C, supporting also architectures >> not >> explicitely tested or developed for. >> >> >> This is true. And this is possible to do under libobjc2 as well. >> >> >> GCC comes with its runtime, for the end user it means one consistent >> setup. >> >> >> Again.. the "they come together" argument. Who cares whether clang >> and libobjc2 are packaged together so long as it works. >> >> Maybe it is installed by default in the system compiler (e.g. >> NetBSD!) or easily with a package (e.g. most Linux installations with >> GCC). On many system clang is shipped, but libobjc2 is either not >> shipped or unusable (e.g. FreeBSD!) which needs building it >> >> >> This is a good point and a lot easier to correct than updating the >> compiler and writing the runtime support as detailed above. >> >> In my opinion it would be unacceptable to drop many of these >> architectures. GNUstep caters to many people, several seek "off >> mainstream" users, running away from GNOME or such. >> >> >> And when they run to us they will find poor support for a version of >> the objective-c language which is verging on 16-17 years old. Do you >> think they will stay? >> >> The late Bernard >> who much spurred me in this project was for example a PPC user as >> myself. >> >> >> We should value architectures in accordance with the audience each has. >> >> >> GCC support on windows is good and I have a quite stable setup, the >> work on msys2 progressed well and appears to be stable on 32bit and >> 64bit as the old gcc 3.4 setup was! Long go - many other setups >> appeared to work but were not production solid. >> >> >> The project I am on uses both clang and GCC in a production >> environment. Memory issues due to the lack of ARC and other workable >> solutions are a constant issue. In 2022 this is not something that we >> as a project should be particularly proud of. >> >> Debian and NetBSD support many architectures, several of them do not >> support clang well and especially do not have libobjc2 support. >> >> >> Agreed. Again, this is something that should be addressed and >> represents less work than the work for GCC. >> >> > 2) GNUstep is an FSF project, so there is a political component >> if we >> > don't >> > support GCC anymore. This is not a show-stopper but is >> something to >> > consider. >> You do not consider it a show stopper, others may! Politics is a very >> personal thing. Politics/Ethics divides people! Just the license made >> people "camp" on GCC or CLang having distributions switch to one or >> the other (and then half-reconsidering the migration because of weak >> platform support ending with mixed setups for years!). >> Because of politics we lost some members of this community. >> Because of licenses and politics there are companies insisting using >> GCC and others CLang/LLVM! so... >> >> >> Not so. Some people whom I have worked with have spent weeks trying >> to get memory issues solved when that time could have been spent doing >> more productive things and, indeed, saved money as well. I am >> wondering why you think that is a political concern. >> >> >> Personally, I deem almost unaccebtale (to use your own words) to >> loose >> "the GNU compiler" since we are a GNU project. My ultimate goal is >> and >> remains to run GNU Emacs with GNUstep interface on GNU/Hurd >> running in >> a whole GNUstep session (GWorkspace, etc) and I am very close to it >> For others, e.g. FreeBSD, the system compiler is Clang, so they just >> want to use that (as I am doing right now, typing this email! GNUMail >> with Clang 10.01 and libobjc2). >> >> >> > 1) ARC >> > 2) support for modern features in objc that are commonly used >> > 3) more developers will be able to port their applications to >> GNUstep >> >> All correct. Also, Clang is the default compiler on FreeBSD and the >> "almost de-facto" on OpenBSD too. >> >> > Disadvantages >> > -- >> > 1) libobjc2 is currently, as stated above, unstable or >> unsupported on >> > some >> > architectures / operating systems. >> >> Here, I add a list >> 1) libobjc2 does not support many platforms and it needs to be tested >> and enhanced on every OS+Arch separately. E.g. it works on x86 on >> Linux, but not on NetBSD >> >> >> As does libobjc. Just because something works on one architecture >> doesn't mean it will work on another. >> >> >> 2) libobjc2 is separate from CLang, so while it the latter is widely >> used and supported, the runtime is mainly David's work. So while >> it is >> amazing what he achieved alone (kudos) it is essentially a one-man >> show, not much worse than the unsupported GCC one. Also, David >> interest in GNUstep itself dwindled >> >> >> Free software and open source is RARELY a one-man show. >> >> >> 3) building libobcj2 does not use the standard autotools and >> gnustep-make setup - "high inconvenience" >> >> >> Correctable >> >> >> 4) building libobjc2 on windows does not work with the msys toolchain >> but requires VS (for me "really unacceptable") >> >> >> Correctable >> >> 5) the whole configuration is fragile, often it does not link with >> the >> system linker, requires another linker which *may* not be even ready >> available >> >> >> go.ld is even supported on PPC... >> https://en.wikipedia.org/wiki/Gold_(linker) >> <https://en.wikipedia.org/wiki/Gold_%28linker%29> >> >> >> 6) exception handling is fragile to get and i never get it >> working, so >> exceptions fall through to unhandled C++ stuff. Exceptions are also >> one of the major issues when porting a supported architecture to a >> new >> OS (e.g. NetBSD/x86) >> >> >> Agreed. >> >> 7) libobjc2 seems slow. Even if David explained a lot of >> optimizations >> in memory usage, method calling.. when running GUI apps it feels >> inferior. This is a qualitative, not a quantitative judgment. >> Also, it >> could depend on clang vs gcc, not just the runtime. >> >> >> I double you have any tests or numbers to back up the claim of it >> being slow. >> >> >> > Approach >> > -- >> > 1) make sure that libobjc2 is supported on as wide a range of >> > platforms as >> > possible. >> > 2) Fix issues with building on Windows/msys2 >> >> Agreed. I will work on it, I can devote more of my systems to >> CLang/libobjc2 if I have two samples of them if we want to work on >> it. >> I did that, but lack of progress with David had me switch to GCC back >> on systems where I planned to "check" >> >> I also would find useful to try to fix the "libobjc2 replacement as >> GCC runtime" as it allows comparison, a gradual approach and also >> e.g. >> testing of 7) to a certain extent. >> >> > We should make the transition as easy as possible for people who are >> > currently using GCC to switch over to Clang/LLVM. >> >> Given the above, for me it is hard to favour a switch, the loss is >> too >> big compared to the gain and uncertainity. But we can think of a more >> inclusive approach, perhaps. THere seem to me several roads open. >> >> For me FOSS means freedom. Not "camp" on GCC or CLang. So the best >> final solution would be to support both compilers, even if accepting >> limitations when using one or the other. That frees us from politics >> and also ensures a better future. >> Maybe in the 5 years Richard is thinking for the transition there >> will >> be a different panorama in the compilers? a new one? a dead one? >> Apple >> drops CLang? An unacceptable change in license (GPL4?) Who knows. As >> long as we are not bound 1:1 like Apple, we have future. >> >> >> 5 years seems to me to be an egregiously long time. >> >> Riccardo >> >> -- >> Proudly sent with GNUMail on GNUstep on FreeBSD/x86-64 >> >> >> GNUmail's only user. ;) >> >> >> -- >> Gregory Casamento >> GNUstep Lead Developer / OLC, Principal Consultant >> http://www.gnustep.org - http://heronsperch.blogspot.com >> https://www.patreon.com/bePatron?u=352392 - Become a Patron >> https://gf.me/u/x8m3sx - My GNUstep GoFundMe >> https://teespring.com/stores/gnustep - Store >
