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

[Nat!]

Am 04.01.2012 um 13:08 schrieb David Chisnall:

Hi David

> 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.
> 
> It's not a linker issue, because there's nothing a linker can do to fix it.

>  Merging objc_module structures requires understanding them, which is 
> incredibly nontrivial - for example, selector references in Objective-C refer 
> to fixed offsets within a selector list, and the module contains a pointer to 
> the start of this list so you'd have to fix up the 

So I don't get it, first you say the linker can't fix it. Then you give a 
recipe how to fix it. So what is it ? :)

> Oddly enough, not being an idiot, I tested it with -fconstant-string-class, 
> and did not hard-code NXConstantString, unless that is omitted.  I'd like to 
> change the default when -fconstant-string-class is omitted to 
> NSConstantString, but last time I did that it broke GNUstep's configure 
> script.

Well I apologise, if that was incorrect. I looked at a patch in r147493, saw 
that NXConstantString was used in a hard coded way:

+ if (StringClass.empty()) StringClass = "NXConstantString";

and then I saw, that the patch was shortly reverted afterwards. So I surmised 
some breakage and since I like to use -fconstant-string-class I get a little 
panicky, if I figure clang is becoming incomatible.

> 

>> 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. 
> 
> Sure, if you want to completely rewrite the linker on every possible platform 
> then be my guest.  Apple can do this, because they only have one linker to 
> worry about.  I do, however, plan on implementing objc_module merging as a 
> link-time optimisation pass at some point.  I'm not currently motivated to do 
> this because the only linker that supports LTO on non-Apple platforms is 
> GPLv3, but this should change in the next couple of months.

That's OK. I probably wouldn't want to do if I was in your shoes either. I need 
to work around it anyway for the next years, since there are too many 
distributions out with the bug. But if I find some time, I might actually take 
a look and try to fix the gcc ld at least. dyld and ld on OS X, don't have this 
problem as the callback is on a true per module basis.


> 
>> If fixes are now done only in clang and not in gcc, that would implicate it 
>> to me.
> 
> You have an aversion to using a permissively licensed compiler with good 
> language support?
> 

I am currently on the fence and try to be compatible with both. Since I am 
really in for the long haul, I would currently expect that gcc is my safe bet 
(for forever :)). What ever happens with clang down the road I don't know. I 
enjoy using it, but I hope I don't have to choose between gcc or clang some 
time.

Ciao
   Nat!

> David
> 
> --
> This email complies with ISO 3103
> 
> 

------------------------------------------------------
This is your life 
and it's ending one minute at a time.  -- Palahniuk