Связывание статических библиотек libm.a или libc.a с NDK cmake

Возможно ли связать платформы \ android-XX \ arch-arm \ usr \ lib * .a версии библиотек при использовании системы сборки NDK Cmake с Android Studio? Я использую LLVM набор инструментов и Android NDK 13.Связывание статических библиотек libm.a или libc.a с NDK cmake

Я пробовал изменения на образце приложения, изменяя файл: https://github.com/googlesamples/android-ndk/blob/master-cmake/hello-jni/app/src/main/cpp/CMakeLists.txt

С следующие изменения (добавление libm.a):

target_link_libraries(hello-jni libm.a android log)

Сборки успешно , но readelf -d показывает, что libm.so все еще связаны между собой:

0x00000001 (NEEDED)      Shared library: [libandroid.so] 
0x00000001 (NEEDED)      Shared library: [liblog.so] 
0x00000001 (NEEDED)      Shared library: [libm.so] 
0x00000001 (NEEDED)      Shared library: [libdl.so] 
0x00000001 (NEEDED)      Shared library: [libc.so]

При добавлении также libc.a становится хуже, здание не может:

Error:error: relocation overflow in R_ARM_THM_JUMP11 
Error:error: linker command failed with exit code 1 (use -v to see invocation)

BTW, иногда я вижу только последнюю ошибку без каких-либо объяснений (например, при названии библиотеки ошибок). Должен ли я установить флаг -v, чтобы увидеть подробности? Как это сделать?

источник

2016-10-11 jozols

Просто FYI, статическая ссылка libc в ваше приложение будет болезненной. У Zygote будет своя копия одного и того же глобального файла, и они будут конфликтующими. –

@ DanAlbert Я вижу. Чтобы быть ясным, вы говорите о некоторых глобальных данных, используемых внутри libc.a, которые используются косвенно и совместно используются пользователями библиотеки? – jozols

Возможно, возможно связать как-то только нужные части из статической библиотеки и избежать проблем с глобальными данными? Я думаю, что при использовании статического связующего линкера импортируются только необходимые вещи. – jozols

Если вы просто хотите, чтобы это было скомпилировано, я бы попытался использовать arm-linux-androideabi-gcc вместо clang. Я понимаю, что gcc обесценивается. Но я не могу, если ваша цель состоит в том, чтобы скомпилировать или понять проблему. Судя комментарий Дэна, я предполагаю, что он не верит в любой из флагов он комментировал в AOSP поможет (ссылка ниже)

https://android.googlesource.com/platform/build/+/master/core/clang/config.mk

FWIW, я, как правило, всегда используют статические LIBS из aosp/bionic builds я делаю, потому что я работаю над многочисленными вещами, которые их требуют. существует слишком много несогласованности в символах, включенных в bionics libc между версиями sdk, и для статической привязки его к использованию libc.a, по большей части, я полагаю. Если вы собираетесь использовать версию статического libc ndk, я бы предложил использовать платформу 21 вместо 24.

Я полагаю, что, поскольку Android настолько фрагментирован, и все устройства используют разные libc.so, libdl.so , и т. д., что это не может вызвать слишком много проблем.

EDIT: неверный вопрос.

источник

2016-10-12 04:24:42 Surge1223

Оказывается, я установил minSdkVersion в 15 в build.gradle (app), поэтому линкер пытался связать libc.a из этой папки. При переключении minSdkVersion на 21 правильную версию libc.a была использована, и все было скомпилировано успешно, хотя readelf по-прежнему показывает libc.so, но я предполагаю, что это связано с тем, что это требуют другие части библиотеки. Но загрузка общей библиотеки не работает как с gcc, так и с clang - только при использовании статического libc.a: 'SIGSEGV (сигнал SIGSEGV: адрес защищен адресом (адрес ошибки: 0x206e7777))' Я предполагаю, что это связано с тем, что статическая версия libc конфликтует с поделился одним, как упоминал Дэн. – jozols

Если вы делаете общую библиотеку, вы не можете связываться с libc.a, вы должны использовать libc.so (ну, можете, но это не очень хорошая идея, как сказал Дэн), извините, я думал, что вы делаете запускаемый файл. Просто я понимаю, почему вы хотите использовать статические библиотеки при создании общей библиотеки? Честно говоря, вы можете сомневаться в статических версиях всех необходимых библиотек, кроме libc. Но опять же я не уверен в том, что вы хотите связать их статически, если ваша цель состоит в создании общей библиотеки. – Surge1223

Конечная цель была также конвертировать * .so в * .a также. Я хотел бы иметь статическое связывание, чтобы избежать легкого переопределения функций C (например, memcpy и т. Д.), Когда кто-то пытается злоупотреблять моей библиотекой. Поскольку эти функции работают с данными, которые я хотел бы скрыть. В чем разница между связыванием статической библиотеки с исполняемой или разделяемой библиотекой в этом контексте? – jozols

Связывание статических библиотек libm.a или libc.a с NDK cmake

ответ

Смежные вопросы