Sorry for the delayed response - I was at a workshop last week and was a bit behind on email.
On 13 May 2018, at 22:08, Ivan Vučica <[hidden email]> wrote:
> to confirm, is current libobjc2 master incompatible with current gnustep-base master?
> Stjepan has been building GNUstep using the following instructions:
> http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux > and I remembered that the failure could be due to the development of the new abi.
This is a bug in libobjc2, which I have now fixed. I forgot that objc_slot was part of the public API and so renamed it to objc_slot_v1, which then broke things. I have now reverted its name to objc_slot and introduced a new objc_slot2, which fixes the issue.
> I powered on the laptop during my vacation, took a quick look, and told him to git checkout 1.9. This seems to have worked.
> Is this intentional?
No, it was a bug (though the master branch of libobjc2 may contain experimental code so may be less reliable than a release).
On a related note, I have had no feedback at all from requests to test the 1.9 and master branches in preparation for the 1.9 and 2.0 releases.
> Presumably -base newabi branch is not ready to be merged yet — but should libobjc2’s master branch be using the new abi then?
I have some other changes in the -base newabi branch. It’s probably fine to merge the changes so support the support for the new NSConstantString parts, but unfortunately the new constant string exposes some bugs in -base’s unicode handling (in particular, incompatibilities with NSString and GSString), which are probably exposed by other NSString subclasses.