Re: Crash in ___lldb_unnamed_symbol / cannot locate symbol "__start___objc_selectors" on Android

[Frederik Seiffert]

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 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