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.
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.
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.
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
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…
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”…