A quick semi-related update on this in case this useful to someone: in order to get Android Studio to locate debug information and resolve the "___lldb_unnamed_symbol" entries I needed to add "-Wl,--build-id=sha1" to the LDFAGS. This is now fixed in our Android toolchain.
Frederik > Am 01.07.2019 um 14:14 schrieb Frederik Seiffert <[email protected]>: > > Hi, > > I’ve been working on using a more up-to-date Clang with the Android toolchain > (in order to use the 2.0 Objective-C runtime), and managed to integrate the > Clang r353983 prebuilt into NDK r20. > > While this seems to work well so far when targeting armeabi-v7a, I am getting > the following errors when targeting arm64. > > > 1. When using Qt to build a simple test app with Objective C, I’m getting the > following runtime error when launching the app: > >> java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol >> "__start___objc_selectors" referenced by >> "/data/app/org.qtproject.example.Qt_test-izIXM5mKlm3teJ8swIY-gQ==/lib/arm64/libQt-test.so"... > > > libQt-test here is the native library containing some basic C++ and Objective > C code. This is linked against libobjc and libgnustep-base. What could be a > reason for this symbol to be missing? > > > 2. When using Android Studio to run the hello-objectivec > <https://github.com/gnustep/android-examples/tree/master/hello-objectivec> > sample app with the new Clang/NDK, I am getting a segmentation fault > (SEGV_ACCERR) with the following backtrace. This seems to be triggered by any > first time Objective C code is run. > >> art_sigsegv_fault 0x0000007ad1109c70 >> art::FaultManager::HandleFault(int, siginfo*, void*) 0x0000007ad110a1a8 >> ___lldb_unnamed_symbol181$$app_process64 0x00000057bdeef13c >> <unknown> 0x0000007b580086a0 >> snprintf 0x0000007b56dc3208 >> snprintf 0x0000007b56dc3208 >> ___lldb_unnamed_symbol3539$$libgnustep-base.so 0x0000007ab649ae20 >> ___lldb_unnamed_symbol3541$$libgnustep-base.so 0x0000007ab649b164 >> ___lldb_unnamed_symbol6841$$libgnustep-base.so 0x0000007ab6638a84 >> objc_msg_lookup_internal 0x0000007ab5f24294 >> objc_msg_lookup_sender 0x0000007ab5f24038 >> ___lldb_unnamed_symbol2600$$libgnustep-base.so 0x0000007ab642bf28 >> ___lldb_unnamed_symbol2599$$libgnustep-base.so 0x0000007ab642be84 >> ___lldb_unnamed_symbol4132$$libgnustep-base.so 0x0000007ab64bf0a4 >> ... (about 24000 similar entries) >> ___lldb_unnamed_symbol1567$$libgnustep-base.so 0x0000007ab6390d38 >> ___lldb_unnamed_symbol1577$$libgnustep-base.so 0x0000007ab63912c0 >> ___lldb_unnamed_symbol5202$$libgnustep-base.so 0x0000007ab65602e8 >> objc_send_initialize 0x0000007ab5f16604 >> objc_msg_lookup_internal 0x0000007ab5f24114 >> objc_msg_lookup_sender 0x0000007ab5f24038 >> ___lldb_unnamed_symbol4106$$libgnustep-base.so 0x0000007ab64bdf70 >> objc_send_initialize 0x0000007ab5f16604 >> objc_send_initialize 0x0000007ab5f162a4 >> objc_msg_lookup_internal 0x0000007ab5f24114 >> objc_msg_lookup_sender 0x0000007ab5f24038 >> Java_com_example_helloobjectivec_MainActivity_initializeGNUstep >> GSInitialize.m:32 > > > > > As I cannot really make sense of either of these I would appreciate anyone’s > thoughts on them. > > Frederik >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
