Thanks for the explanation David.

> I believe there was a bug in clang where I didn't add an empty symbol for 
> compilation units that didn't contain any selectors.  If you then linked a 
> program or a library that didn't contain any selectors then you'd see this 
> error at link time.  This should now be fixed, but you can work around it by 
> making sure that at least one of the Objective-C[++] files that you link 
> includes at least one use of a selector.

After skimming CGObjCGNU.cpp in Clang I had the exact same thought, but I had 
only added ObjC code/selectors, not ObjC++. After adding both the app links 
fine. (Btw. I don’t think CGObjCGNU.cpp 
<https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CGObjCGNU.cpp#L927-L939>
 currently emits empty symbols for selectors if none are found, only for 
protocols and classes).

However, now the Qt app also fails with the same backtrace as the one in 
Android Studio (issue #2 from my original email), but Qt’s debugger is showing 
me more info and think I have an idea about what’s going on now.

I think for some reason objc_send_initialize() is being called on classes 
before Objective C categories have been loaded. This causes various 
unrecognized selector calls because many internal functions in GNUstep are 
implemented in categories (e.g. NSObject (GNUstepBase)). In my specific stack 
trace, +[NSException raise:format:arguments:] was calling +[NSString 
stringWithFormat:arguments:] (implemented in the GNUstepBase NSString 
category), causing another exception ad infinitum. Replacing that NSString call 
in NSException with a non-category version causes it to crash in various other 
initializers calling category methods.

I know on Apple platforms one must pass -all_load or -force_load to the linker 
to use categories in static libraries, but this doesn’t seem to be recognized 
by my linker (and doesn’t seem to be necessary for other ABIs). Is there 
anything else that might be going on here?

Thanks,
Frederik

_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Reply via email to