-fnext-runtime vs. -fgnu-runtime smackdown, #6, symbols

The lights come back up at the smackdown and the bell rings, GNU runtime interface is looking rejuvenated as the cocky NeXT runtime interface dances around the ring. When the lights were low, the GNU runtime interface's manager tucked a pair of underscores into the gloves. GNU runtime interface comes out strong and socks the NeXT runtime interface in the eye. Oh, that has got to hurt.

gcc emits object file symbols for classes and categories. Afterall, it is nice to be able to reference classes in other object files isn't it. I don't know about categories though, is this actually used? Anyway. There are actually a couple (as in two) ways to reference classes in other object files. One is objc_get_class/objc_getClass, this asks the runtime for a class. A call to this function with the classes name can be generated instead of a direct reference. The alternative is to generate actual object file symbols for the class.

-fnext-runtime generates class symbols which look like this:

_.objc_class_name_MyClass

-fgnu-runtime generates class symbols which look like this:

___objc_class_name_MyClass

The thing is, these really have nothing to do with the runtime, the runtime doesn't care about object file symbols. They are strictly platform specific, some linkers can deal with periods in symbols, some can't.

I have no idea why NeXT chose to use a period in a symbol, probably to keep the linking namespace a little more organized, either way, it's not entirely portable. The mainline binutils can not deal with these symbols on Windows, I expect it is a similar situation on other platforms.

-fgnu-runtime wins out on this one, but not by much. Underscores should be the default.

Add a compiler flag -fobjc-period-symbols to enable the NeXT style.

-fgnu-runtime: 2
-fnext-runtime: 2