On Wednesday, January 4, 2012 13:08 CET, David Chisnall <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
