Linking STL in eine eigenständige Android NDK ausführbare

Der folgende Code erzeugt einen Segmentation Fault, nachdem die Zeichenfolge Druck:Linking STL in eine eigenständige Android NDK ausführbare

#include <iostream> 
using namespace std; 

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

Wenn ich cout zu printf ändern, ist es nicht zum Absturz bringen.
Wenn ich cout in einer anderen Funktion als Main aufrufen, und dass Funktion nie zugegriffen wird, stürzt es immer noch ab.
Es stürzt auf Froyo, aber nicht ICS.

Als Referenz ist hier mein Android.mk:

LOCAL_PATH:= $(call my-dir) 

include $(CLEAR_VARS) 

LOCAL_MODULE := ndktest 
LOCAL_SRC_FILES := main.cpp 

include $(BUILD_EXECUTABLE)

und Application.mk:

APP_STL := stlport_static

Hier ist der Absturz von logcat ist:

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)

das Laufen durch Das Stack-Trace-Tool lieferte keine symbolischen Informationen.

Update:

Der PC-Wert im Crash-Dump (0001972c in /system/lib/libc.so) in einer Exit-Routine, die mit Absturz, nachdem die Zeichenfolge im Einklang gedruckt wird:

Quelle

2012-07-06 Ravi

Haben Sie noch nicht nachgedacht, wie Sie 'LOCAL_LDLIBS + = -ldl' und' LOCAL_SHARED_LIBRARIES + = libdl' in Ihr Android.mk einfügen? Der Grund, warum ich 'dl' sage, ist der dynamische Linkabschnitt, der in der gemeinsam genutzten Bibliothek für den stlport verlinkt. – t0mm13b

@ t0mm13b: Ich habe das versucht, bekomme aber trotzdem "CAN NOT LINK EXECUTABLE" wenn ich das Programm starte. Wie würde ich libstlport_shared.so in main() laden? – 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-or-stlport-for-android <- der letzte linky könnte die Antwort sein ... schau es dir an :) – t0mm13b

Dies ist wahrscheinlich aufgrund der Tatsache, dass Sie stlport_static anstelle von stlport_shared verwenden.

In den NDK-Dokumenten (CPLUSPLUS-SUPPORT.html im Lieferumfang enthalten) wird dieses Verhalten beschrieben. Dieses unvorhergesehene Verhalten rührt von der Tatsache her, dass, wenn die Anwendung mit zwei (oder mehr) gemeinsam genutzten Bibliotheken verknüpft wird und beide mit stlport_static verknüpfen, einige Symbole dupliziert werden können, was zu einem falschen Verhalten führt.

Quelle

2012-07-09 15:47:53 Sdra

Ich habe keine gemeinsam genutzten Bibliotheken in meinem Projekt. In meinem obigen Makefile baue ich nur eine ausführbare Datei, die STL statisch verknüpft. Gibt es einen Grund, warum ich zu einer freigegebenen Version von STL wechseln müsste? – Ravi

@Ravi: Versuchen Sie es und sehen, ob es funktioniert ... – Goz

Ich bin nicht klar, wie Sie STL als eine gemeinsame Bibliothek auf der NDK-Ebene verwenden. Wenn ich stlport_shared verwende, wird in der Dokumentation angegeben, die Bibliothek in einem statischen Java-Initialisierer zu laden. Bedeutet das, dass ich das als eine apk bauen muss? Ich versuche, dieses Projekt als reine NDK-Programmdatei zu erhalten, da es über eine Befehlszeilenschnittstelle verfügt, und ich möchte es zu einem Teil von/system/xbin machen. – Ravi

Linking STL in eine eigenständige Android NDK ausführbare

Antwort

Verwandte Themen