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 _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
