Whatever the problem is, I don't think it's in the info you posted
(which doesn't look like real code).
For debugging purposes the real code was a comment-out mess.
*sigh* I pinned it down to an typo in the real code, actually an "C-
string" literal instead of an @"NSString". I really shouldn't code
influenced by some influenca...
Debugging was partially tricky, Xcode / gdb most of the time failed
with a sigsegv, alternating with
"Xcode: Introspection dylib not loaded because thread 1 has function:
__dyld__ZN4dyld12notifySingleE17dyld_image_statesPK11mach_headerPKcl
on stack", i.e. dyld::notifySingle(dyld_image_states, mach_header
const*, char const*, long).
The docs on +load are too paranoid, and are due to be revised. As of
Leopard, you can count on all +load methods in frameworks you link to
be called before any +load method in your code.
OK, great for the clarification. Otherwise I had rewritten the code
anyway.
Though, the autoreleased dictionary would
leak and spew a log to the console due to there being no autorelease
pool in place at this point.
Thanks for that hint.
The message to TELibraryFactory is safe in that the class object will
exist at this point, but if the class has a +load method, it may not
have run yet. TELibraryFactory's +load will run before that of any of
its subclasses, though.
My first variant used a C function to prevent any race conditions. So
the Leopard +load order is also baseclass to subclasses, like
+initialize?
