I was able to build gcc 11.2.0 with objective c++ activated in the standard haikuports recipe. I uninstalled gcc with pkgman. Then I installed my custom build by copying to /system/packages and had it working. I just ran a full-sync to update haiku. When I did so, it updated gcc back to the standard version.
What are some ways to make my custom gcc install pervasive across updates? I assume there are several ways I could go about doing this, but I’m not sure what I should try.
Does libobjc work? If it does, then GNUstep could be ported.
It compiled without problem. So far my reasoning behind adding this was because running ./configure on Dogecoin Core throws a bunch of objective c++ missing errors. So far I have quieted those errors, but still haven’t gotten ./configure to complete due to it not finding the boost::system immediately after it checked for and found boost::system.
A full-sync will also downgrade and remove packages. I never use full-sync, just pkgman refresh and pkgman update
Do you have the boost170_devel package installed?
Possibly you have to rebuild the boost package with your freshly baked gcc.
Keep in mind, you should adjust the recipes and create a pull request to make your changes stick.
However throwing objc++ into the GCC recipe isnt enough, you supposed to split it into an own subpackage, like we did with the fortran stuff. Check the recipe for more info.
No, you would also need to port libobj2 for modern Objective-C Features. Also, libdispatch, is recommended in this case.
Welcome Linuxism package madness…
libobjc2 isn’t required or even supported by GCC. GNUstep itself also works without libobjc2.
If you stay with the old GNU things and Applications, yes, that may work. But GCC libobjc is such an old implementation that it completely useless today. Modern language things like ARC are not supported.
It would not even try to port a Mac OS X application with this, it is not worth the effort.
http://wiki.gnustep.org/index.php/ObjC2_FAQ
But that’s not the only reason to get Objective C running. For example we could port objfw.
So, if we just enable objective-C in the compiler, and enable no libraries/frameworks, we don’t need to package anything separately, right? And we can then later port libobjc2 as a separate package.
The GCC package already pretty big, nobody should be forced to download your favorite compiler addition if not necessary only because you want to spare some work.
Yes. And I’ve tried every other available version of boostxxx_devel.
I’m getting there as I get time.
It always depends on what you want to archive with an objc implementation. If you want to port some older Mac OS X applications, objfw is not of much use.
If you want to establish a Haiku-Objc environment, then objcfw maybe a solution. As a long time Cocoa developer, I for example have no idea what to do with objfw… 
BTW, libobjc2 compiles fine under Haiku with latest clang. But GNUstep fails to do anything useful with it…
“Old GNU things” is exactly what I plan to work on porting, as a hobby project. It has nothing to do with Mac OS X.
I am looking forward to it. I tried it for the last time a couple of months ago, but I used libobjc2 and clang for that. Base was compiling fine, but completely failed on the test. Every compiled test binary simple gave a “bad access”…
When I poked around in the porter recipe, objective c was already enabled when I got there. I only flipped the switch for objective c++