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
