gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiple _OBJC_Module in the same shared library/framework, not so g


From: Richard Frith-Macdonald
Subject: Re: Multiple _OBJC_Module in the same shared library/framework, not so good
Date: Wed, 4 Jan 2012 11:24:50 +0000

On 4 Jan 2012, at 10:36, Nat! wrote:

> 
> Am 04.01.2012 um 00:25 schrieb David Chisnall:
> 
>> Hi Nat,
>> 
> Hi David,
> 
> 
>> This is, unfortunately, a limitation imposed on us by the old GCC ABI.
> 
> That reads to me as "inevitable", which I can't agree with, due to this being 
> IMO a linker issue.
> 
>> 
>> 
>> With the non-fragile ABI (and clang's transitional ABI), classes all export 
>> a public symbol, so it is possible for us to initialise the isa pointer as a 
>> weak reference to the public symbol for the NSConstantString class so that 
>> the fixup in the runtime becomes redundant.  This is done in clang r147493 
>> and your test case now passes for me.  It should work as long as 
>> GNUstep-base is compiled with clang.  If it was not, then the weak symbol 
>> will be resolved to null at link time and you will see the same crash.
> 
> Seems to have been reverted already. The quick fix to hardcode 
> NXConstantString is really bad, because it breaks -fconstant-string-class.
> 
> Anway, I still think the proper solution would be to improve the linker to 
> coalesce multiple _OBJC_Module into one. This would have also the side 
> benefits of a bit faster startup time and a bit smaller object files. 
> 
> I hope the gcc compiler isn't abandoned now by GNU/GNUstep ? If fixes are now 
> done only in clang and not in gcc, that would implicate it to me.

This (generally speaking) isn't a gnustep specific issue though ... as far as I 
know it's always been the case for Apple as well as GNU that the +load method 
is explicitly documented as not being safe to contain any ObjC code ... you are 
really only supposed to use C code there.

The exact nature of what you can get away with (and what the bad consequences 
of using ObjC code inside +load are) may vary, but you should probably try to 
avoid doing it altogether.

That being saids, I agree that it would be nice if we could define a clear set 
of rules about what you can expect to get away with, and if we could make the 
GNUstep implementation match the Apple implementation (always bearing in mind 
that Apple may change their implementation behavior without notice since we 
shouldn't officially be depending on a specific behavior of ObjC code in + 
load).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]