2014-10-13 3 views
0

Windows에서 Android NDK를 사용하여 arm-v7a에 대한 여러 C++ 라이브러리 세트를 컴파일 중입니다. 나는 대부분 ndk-build를 사용하여 컴파일하고있다. 그러나 내가 사용하고있는 라이브러리 중 하나 (libproblem.so라고 부름)는 다소 복잡한 makefile을 가지고 있으므로, 리눅스에 메이크 파일을 호출하여 해당 라이브러리 만 빌드하도록 ajb-tools (https://subversion.assembla.com/svn/ajb-tools/trunk/android/android-cross/android-cross)를 사용합니다. 두 제품 모두 동일한 NDK 버전을 사용합니다.리눅스 호스트에 구축 된 Android 공유 라이브러리가 Windows 호스트의 라이브러리 빌드와 제대로 연결되지 않음

export ANDROID_GCCVER=${ANDROID_GCCVER-4.8} 
export ANDROID_PLAT_API_VER=${ANDROID_PLAT_API_VER-10} #not sure what this does... 
export ANDROID_PLAT_NDK_VER=${ANDROID_PLAT_NDK_VER-9} #gingerbread 
export ANDROID_TUNE=${ANDROID_TUNE-"-mandroid $ANDROID_TUNE_THUMB -mthumb-interwork -Wno-psabi -fpic -funwind-tables -fstack-protector -march=armv7-a -finline-limit=64"} 

이 잘 작동하는 것 같다, 나에게 그 출력 라이브러리를 제공합니다

나는 포함, 내 Application.mk에 맞게 안드로이드 크로스 스크립트의 기본값을 일부 변경했습니다 file 나에게주는이 : 다음 내 Makefile.mk에 다음을 사용하여 다른 라이브러리를 연결하고

../obj/local/armeabi-v7a/libproblem.so: ELF 32-bit LSB shared object, ARM, 
version 1 (SYSV), dynamically linked (uses shared libs), not stripped 

.

include $(CLEAR_VARS) 
LOCAL_MODULE := problem 
LOCAL_SRC_FILES := $(JNI_PATH)/../libs/prebuilt/$(TARGET_ARCH_ABI)/libproblem.so 
include $(PREBUILT_SHARED_LIBRARY) 

그러나 연결 오류가 발생합니다. libproblem에 의존하는 라이브러리는 다음과 같은 공유 객체를 생성하지 못합니다 :

d:/Code/project/jni/SomeCode.cpp:191: error: undefined reference to 'Problem::Client::Client(std::shared_ptr<Problem::Data> const&)' 

물론 기능은 있습니다. MinGW에서 libproblem.so에 nm을 실행하면 해당 함수가 표시됩니다 (맹 글링 됨).

나의 유일한 생각은 현재 두 개의 다른 호스트 OS를 사용하는 데 문제가 있다는 것입니다. 특히 이상한 점은 ndk-build를 실행하기 위해 linux를 호스트 OS로 사용하면 ndk-build가 libproblem.so를 나머지 객체와 성공적으로 링크하는 것입니다. (Linux와 Windows는 동일한 NDK 버전, NDKr10b, 64 비트 호스트 용 32 비트 타겟을 가지고 있습니다.)

또는 ndk-build의 내 버전과 호환되지 않는 방식으로 해당 라이브러리를 빌드하고있는 android-cross 스크립트에서 뭔가를 놓쳤습니까?

업데이트 : 실패한 연결 명령은 다음과 같습니다. 당신이 마지막 링크 명령하고 생성하는 전체 오류 메시지를 표시 할 수 있다면

/c/Android/android-ndk-r10b/toolchains/arm-linux-androideabi-4.8/prebuilt/windows- 
x86_64/bin/arm-linux-androideabi-g++ -Wl,-soname,libFinal.so -shared 
--sysroot=c:/Android/android-ndk-r10b/platforms/android-9/arch-arm d:/Code/project 
/obj/local/armeabi-v7a/objs/Final/Final.o d:/Code/project/jni/../libs/prebuilt/ 
armeabi-v7a/libboost_system.a d:/Code/project/jni/../libs/prebuilt/armeabi- 
v7a/libboost_date_time.a d:/Code/project/jni/../libs/prebuilt/armeabi- 
v7a/libboost_filesystem.a -lgcc d:/Code/project/obj/local/armeabi-v7a/ 
lib1noproblem.so d:/Code/project/obj/local/armeabi-v7a/lib2noproblem.so d:/Code/ 
project/obj/local/armeabi-v7a/libproblem.so d:/Code/project/obj/local/armeabi- 
v7a/libgnustl_shared.so -no-canonical-prefixes -march=armv7-a -Wl,--fix-cortex-a8 
-Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Lc:/Android/ 
android-ndk-r10b/platforms/android-9/arch-arm/usr/lib -lm -llog c:/Android/ 
android-ndk-r10b/sources/cxx-stl/gnu-libstdc++/4.8/libs/armeabi-v7a/libsupc++.a 
-lc -lm -o d:/Code/project/obj/local/armeabi-v7a/libFinal.so 
+0

함수 이름이 올바르게 맹 글링되었는지 확인합시다. 빈'Problem :: Client :: Client (std :: shared_ptr const>)'를 정의한 Windows에서 공유 libDummyProblem.so를 빌드하고 생성 된 실제 lib의 ** nm **를 비교하십시오 Linux에서. –

답변

0

유용 할 것이다. 라이브러리의 순서는 ELF 라이브러리를 연결할 때 중요합니다. 정의되지 않은 참조는 그 라이브러리에서 가져올 수 있습니다.

'ndk-build V = 1'을 사용하여 빌드 명령을 덤프하십시오.

+0

추가했습니다. 문제를 해결하지 못했습니다. 이제는 ndk-build 대신 ajb-tools를 사용하여 모든 코드를 작성했습니다. – rod

+0

누락 된 함수가 링크 명령에 표시되는 라이브러리 중 하나 인 libproblem.so 및 SomeCode.cpp에 있다고 가정하면 문제가되지 않는 것 같습니다. – Digit

+0

링커가 찾지 못하는 libproblem.so의 C++ 기능에 대한 가시성에 대해 말씀해 주시겠습니까? 정확한 (맹 글링 된) 이름은 무엇이며 공개적으로 볼 수 있습니까? 즉이 특정 기호에 대한 "nm"명령의 정확한 출력은 무엇입니까? – Digit