[Top][All Lists]
[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).
- Multiple _OBJC_Module in the same shared library/framework, not so good, Nat!, 2012/01/03
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, David Chisnall, 2012/01/03
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, Nat!, 2012/01/04
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good,
Richard Frith-Macdonald <=
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, David Chisnall, 2012/01/04
- =?utf-8?q?Re:_Multiple_=5FOBJC=5FModule_in_the_same_shared_library/framework, =09not_so_good?=, Sebastian Reitenbach, 2012/01/04
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, Nat!, 2012/01/04
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, David Chisnall, 2012/01/04
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, Matt Rice, 2012/01/04
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, Nat!, 2012/01/07
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, David Chisnall, 2012/01/07
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, Nat!, 2012/01/07
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, Richard Frith-Macdonald, 2012/01/08
- Re: Multiple _OBJC_Module in the same shared library/framework, not so good, Nat!, 2012/01/09