Ahhhh. Awesome. Thanks kindly for posting this. This helps. -Jordan
> On Jul 29, 2019, at 5:19 AM, Frederik Seiffert <frede...@algoriddim.com> > wrote: > > 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 <frede...@algoriddim.com >> <mailto:frede...@algoriddim.com>>: >> >> 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 > Discuss-gnustep@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep
_______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
