=?utf-8?q?Re:_Multiple_=5FOBJC=5FModule_in_the_same_shared_library/framework, =09not_so_good?=

[Sebastian Reitenbach]

On Wednesday, January 4, 2012 13:08 CET, David Chisnall <address@hidden> wrote: 
 
> 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 
> 
> >> 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.
> 
> Ugh, someone reverted it because the test failed, even though the problem was 
> the test, not the code.  It's now back and the test is fixed.
> 
> > The quick fix to hardcode NXConstantString is really bad, because it breaks 
> > -fconstant-string-class.
> 
> 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.
> 
> The fix was not to hardcode NXConstantString, it was (as I said) to 
> initialise the strings isa pointers with a weak reference to the string class 
> (NXConstantString or whatever is specified on the command line) - exactly the 
> same constant string class that is specified by name at the start of the 
> list.  
> 
> > 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.
> 
> > I hope the gcc compiler isn't abandoned now by GNU/GNUstep ?
> 
> No compiler is developed as part of GNUstep.  Nicola Pero contributes to 
> Objective-C support in GCC, I contribute to Clang.  Currently, however, Clang 
> is at feature-parity on Apple and non-Apple platforms, while GCC just about 
> supports Objective-C from the OS X 10.4 era.  If you want to use the 
> non-fragile ABI, fast message dispatch, blocks, or automatic reference 
> counting, for example, then clang is currently your only choice.  For me, 
> going back to using Objective-C without ARC is now quite painful.
> 
> The decision by the FSF to make GCC GPLv3 has also made it unacceptable to 
> some places downstream.  FreeBSD, for example, is in the process of removing 
> GCC (currently GCC 4.2.1, the last GPLv2 version) from the base system, in 
> favour of clang.  I believe OpenBSD will be replacing GCC 4.2.1 with PCC 
> (which has no Objective-C support) and is now using clang to compile the 
> packages.

Already a bit off-topic but on OpenBSD still using the system gcc-4.2.1, on the 
three supported platforms (i386/amd64/macppc). clang 3.0 is in the ports tree, 
and I did a lot of tests with it, but it has issues, i.e. no relocatable 
symbols or what it was on macppc? Also when compiling with optimization -O2 or 
higher, then the GUI applications are unusable, you remember the screenshot I 
sent you? ;) Also besides lots of tests with libobjc2, its also not yet in the 
tree and used, actually waiting on a gnustep -base/gui/back release, and 
especially the last Gorm release doesn't build with it.

Well, more on the progress I made on OpenBSD over the last year, and the issues 
I ran into, at the FOSDEM.

cheers,
Sebastian


> 
> You are, of course, free to choose whatever compiler you want, but be aware 
> that gcc is going to have problems with any code written for Apple platforms 
> in the last few years.
> 
> > 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?
> 
> David
> 
> --
> This email complies with ISO 3103
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev