Łączenie STL do samodzielnego Android NDK wykonywalnego

Poniższy kod powoduje błąd segmentacji po wydrukowaniu ciąg:Łączenie STL do samodzielnego Android NDK wykonywalnego

#include <iostream> 
using namespace std; 

int main() 
{ 
    cout << "ndktest" << endl; 
    return 0; 
}

Gdybym cout zmienić printf, to nie psuje.
Jeśli wywołasz cout w innej funkcji niż główna, a funkcja nigdy nie jest dostępna, nadal ulega awarii.
To zawiesza się na Froyo, ale nie ICS.

Dla porównania, oto moja Android.mk:

LOCAL_PATH:= $(call my-dir) 

include $(CLEAR_VARS) 

LOCAL_MODULE := ndktest 
LOCAL_SRC_FILES := main.cpp 

include $(BUILD_EXECUTABLE)

i Application.mk:

APP_STL := stlport_static

Oto katastrofa od LogCat:

I/DEBUG ( 872): pid: 4234, tid: 4234 >>> /data/ndktest <<< 
I/DEBUG ( 872): signal 11 (SIGSEGV), fault addr 00024004 
I/DEBUG ( 872): r0 00033824 r1 00001000 r2 00024005 r3 bea42cfc 
I/DEBUG ( 872): r4 40008090 r5 0000000a r6 40008000 r7 afd42328 
I/DEBUG ( 872): r8 00000000 r9 00000000 10 00000000 fp 00000000 
I/DEBUG ( 872): ip 40008084 sp bea42ce8 lr afd192dd pc 00024004 cpsr 60000030 
I/DEBUG ( 872): d0 0000000000000000 d1 0000000000000000 
I/DEBUG ( 872): d2 0000000000000000 d3 0000000000000000 
I/DEBUG ( 872): d4 0000000000000000 d5 0000000000000000 
I/DEBUG ( 872): d6 0000000000000000 d7 0000000000000000 
I/DEBUG ( 872): d8 0000000000000000 d9 0000000000000000 
I/DEBUG ( 872): d10 0000000000000000 d11 0000000000000000 
I/DEBUG ( 872): d12 0000000000000000 d13 0000000000000000 
I/DEBUG ( 872): d14 0000000000000000 d15 0000000000000000 
I/DEBUG ( 872): scr 00000000 
I/DEBUG ( 872): 
I/DEBUG ( 872):   #00 pc 00024004 
I/DEBUG ( 872):   #01 pc 000192da /system/lib/libc.so 
I/DEBUG ( 872):   #02 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #03 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #04 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #05 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #06 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #07 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #08 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #09 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #10 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #11 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #12 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #13 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #14 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #15 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #16 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #17 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #18 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #19 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #20 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #21 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #22 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #23 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #24 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #25 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #26 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #27 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #28 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #29 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #30 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872):   #31 pc 0001972c /system/lib/libc.so 
I/DEBUG ( 872): 
I/DEBUG ( 872): code around pc: 
I/DEBUG ( 872): 00023fe4 ffffffff ffffffff ffffffff ffffffff 
I/DEBUG ( 872): 00023ff4 ffffffff ffffffff ffffffff ffffffff 
I/DEBUG ( 872): 00024004 ffffffff ffffffff ffffffff ffffffff 
I/DEBUG ( 872): 00024014 ffffffff ffffffff ffffffff ffffffff 
I/DEBUG ( 872): 00024024 ffffffff ffffffff ffffffff ffffffff 
I/DEBUG ( 872): 
I/DEBUG ( 872): code around lr: 
I/DEBUG ( 872): afd192bc f8cde018 f7f4e00c b930ec56 0c0cf844 
I/DEBUG ( 872): afd192cc 46302201 f7f49900 9803ec4e 47909a05 
I/DEBUG ( 872): afd192dc f1153c0c d5d735ff 2e006836 463cd1ce 
I/DEBUG ( 872): afd192ec b9b99901 c03cf8df 300cf857 f8471e58 
I/DEBUG ( 872): afd192fc b978000c 587a490c e0046810 68059900 
I/DEBUG ( 872): 
I/DEBUG ( 872): stack: 
I/DEBUG ( 872):  bea42ca8 b000c9b8 
I/DEBUG ( 872):  bea42cac 00000014 
I/DEBUG ( 872):  bea42cb0 b00093e0 /system/bin/linker 
I/DEBUG ( 872):  bea42cb4 b001e9b8 
I/DEBUG ( 872):  bea42cb8 b000c9b8 
I/DEBUG ( 872):  bea42cbc b0001c78 /system/bin/linker 
I/DEBUG ( 872):  bea42cc0 b001e724 
I/DEBUG ( 872):  bea42cc4 00000005 
I/DEBUG ( 872):  bea42cc8 b000c9b8 
I/DEBUG ( 872):  bea42ccc b0001de3 /system/bin/linker 
I/DEBUG ( 872):  bea42cd0 b000c9b8 
I/DEBUG ( 872):  bea42cd4 b0002c77 /system/bin/linker 
I/DEBUG ( 872):  bea42cd8 00000000 
I/DEBUG ( 872):  bea42cdc b001ffe8 
I/DEBUG ( 872):  bea42ce0 df002777 
I/DEBUG ( 872):  bea42ce4 e3a070ad 
I/DEBUG ( 872): #01 bea42ce8 00001000 
I/DEBUG ( 872):  bea42cec 00000000 
I/DEBUG ( 872):  bea42cf0 bea42cfc 
I/DEBUG ( 872):  bea42cf4 00033824 
I/DEBUG ( 872):  bea42cf8 00000000 
I/DEBUG ( 872):  bea42cfc 00024005 
I/DEBUG ( 872):  bea42d00 00033824 
I/DEBUG ( 872):  bea42d04 00000000 
I/DEBUG ( 872):  bea42d08 00000000 
I/DEBUG ( 872):  bea42d0c 00000000 
I/DEBUG ( 872):  bea42d10 b000c9b8 
I/DEBUG ( 872):  bea42d14 00000000 
I/DEBUG ( 872):  bea42d18 00000000 
I/DEBUG ( 872):  bea42d1c afd19731 /system/lib/libc.so 
I/BootReceiver( 946): Copying /data/tombstones/tombstone_09 to DropBox (SYSTEM_TOMBSTONE)

Running to poprzez narzędzie śledzenia stosu nie przyniosło żadnych informacji symbolicznych.

Aktualizacja:

Wartość pc na zrzut awaryjny (0001972c w /system/lib/libc.so) znajduje się w rutynowych wyjścia, co jest zgodne z upaść po ciąg jest drukowany:

00019728 <exit>: 
    19728: 4604  mov r4, r0 
    1972a: 2000  movs r0, #0 
    1972c: f7ff fd8c bl 19248 <__cxa_finalize> 
    19730: 4620  mov r0, r4 
    19732: f7f3 ee96 blx d460 <_exit> 
    19736: bf00  nop

Źródło

2012-07-06 Ravi

Nie zaglądałeś do dodawania 'LOCAL_LDLIBS + = -ldl' i' LOCAL_SHARED_LIBRARIES + = libdl' do twojego Android.mk? Powodem, dla którego mówię konkretnie "dl", jest dynamiczna łącząca część do połączenia w bibliotece współdzielonej dla tej ostatniej. – t0mm13b

@ t0mm13b: Próbowałem, ale nadal otrzymuję komunikat "CAN NOT LINK EXECUTABLE", gdy uruchamiam program. Jak mogę załadować libstlport_shared.so w main()? – Ravi

http://stackoverflow.com/questions/7339229/android-std-and-stl-support, http://sseyod.blogspot.ie/2009/08/android-jni-ndk-and-stl-support.html , http://stackoverflow.com/questions/1650963/ustl-lub-stlport-for-android <- ostatni link może być odpowiedzią ... sprawdź to :) – t0mm13b

Jest tak prawdopodobnie z powodu użycia stlport_static zamiast stlport_shared.

W dokumentacji NDK (CPLUSPLUS-SUPPORT.html dołączonej do pakietu) zachowanie to jest opisane. To nieprzewidziane zachowanie wynika z faktu, że jeśli aplikacja łączy się z dwiema (lub więcej) bibliotekami współdzielonymi i łączy się ze stlport_static, niektóre symbole mogą być duplikowane, co prowadzi do nieprawidłowego zachowania.

Źródło

2012-07-09 15:47:53 Sdra

Nie mam żadnych udostępnionych bibliotek w moim projekcie. W powyższym pliku Makefile właśnie buduję jeden plik wykonywalny, który statycznie łączy STL. Czy jest jakiś powód, dla którego musiałbym przejść do wspólnej wersji STL? – Ravi

@Ravi: Wypróbuj i sprawdź, czy działa ... – Goz

Nie wiem, jak używać STL jako biblioteki współdzielonej w warstwie NDK. Jeśli używam stlport_shared, dokumentacja mówi, aby załadować bibliotekę w statycznym inicjatorze Java. Czy to oznacza, że muszę zbudować to jako apk? Próbuję zachować ten projekt jako czysty plik wykonywalny NDK, ponieważ ma on interfejs wiersza polecenia i chciałbym uczynić go częścią/system/xbin. – Ravi

Łączenie STL do samodzielnego Android NDK wykonywalnego

Odpowiedz

Powiązane problemy