__objc_exec_class is called before __objc_load when staticly linked

[minusbat]

The normal order when dynamically linked is that __objc_load() is called to load the 'Protocol' class, and then __objc_exec_class() is called to load 'Cls'. As _objc_load detects 'Protocol' and resets the ABI back to 'UnknownABI' then this allows the use of the 1.9 ABI.

When staticly linked, however, __objc_exec_class() is called first, which sets the ABI to 'LegacyABI' and then when __objc_load() is called with 'Protocol' then the check on the ABI version aborts.

( this is kind of a reopening of #85 )

I am unsure as to why the order is different between the two types of linking, or how to get around this. As the loading of 'Protocol' is used to detect the different ABI's I can see ways to recode this to make it still detect mixed ABI's and abort, but the sketch I have in my head is ugly. It would be better if the functions could be guaranteed to run in the same order under both situations, but I don't know if thats possible.

[minusbat]

So, I implemented a less ugly version of the fix in my head and submitted a pull request. This fixes the ABI mixing issue, though I am running into other problems staticky linking the 1.9 Abi against the master library, but will investigate those later and do a separate issue and pull request.

[davidchisnall]

I believe that #294 may fix this.

[ingresso-pete]

Oh, excellent! I shall give it a try when I get a moment (may have to wait until next week). I am still using the 1.9 ABI happily enough, but would love to move to 2.0, so thankyou!

[ and there was me thinking everyone had gone to Swift... ;-) ]