Вопрос по libc, android – Статическое связывание Android против динамического связывания с glibc

10

Я кросс-компилировал некоторые инструменты Linux (и некоторые из моего собственного кода C) для Android, и одна из проблем, с которыми я сталкиваюсь, состоит в том, что в libc Android есть некоторые отсутствующие / раздетые компоненты, и я в итоге исправляю свой код, чтобы сделать его работать с libc Android (например, для такой проблемы, как эта)http://credentiality2.blogspot.com/2010/08/compile-ncurses-for-android.html)

Q1: Как мне статически связываться с glibc (и другими зависимостями) при кросс-компиляции с помощью набора инструментов arm (или ndk-build)?

Q2: Это хорошая идея статически связать с glibc для двоичных файлов для Android? Стоит ли ожидать, что что-то сломается, если я начну статически связывать? Есть ли проблемы с производительностью / памятью?

Я понимаю большинство плюсов и минусов статического и динамического связывания отсюда - Приложение C ++ - использовать ли статические или динамические ссылки для библиотек? а также Статическое связывание против динамического связывания

Поэтому я хотел бы знать, должен ли я статически связывать glibc для Android при кросс-компиляции двоичных файлов.

Ваш Ответ

2   ответа
5

Сначала небольшая заметка о libc. Android libc - это Bionic libc (https://github.com/android/platform_bionic/), а не GNU libc (glibc). Таким образом, libc, содержащийся в NDK, является Bionic, как и libc, доступный на устройствах Android.

Что касается glibc, его можно построить с помощью NDK. Однако его имя будет конфликтовать с системным libc при установке на устройства Android. Обратите внимание, что это только если вы идете для создания динамической библиотеки. Если вы собираете GNU libc как статическую библиотеку, то весь вопрос, описанный выше, обходится стороной, так как вам никогда не нужно устанавливать статическую библиотеку.

Теперь, чтобы ответить на ваши вопросы:

  1. Q1: If you're building the glibc using the NDK, then the Android.mk uses the variable BUILD_STATIC_LIBRARY to build static libraries. However, if you dont use the NDK, then you'll probably need to get into the a lot of headache(dont know how much). I can't tell you more on this as I haven't tried a build of glibc, either static or dynamic. Also, it seems that static linking with glibc is highly discouraged, at-least for non-mobile platforms.

  2. From a breakage viewpoint, there is no difference between static and dynamic linking. From a start-up viewpoint, a static executable start up faster as the dynamic libraries loading step is not needed. There is no memory or execution speed penalty in either static or dynamic linked executables. Disk storage requirement is larger for static executables.

Что касается проблем с отсутствующей функциональностью bionic libc, вы можете использовать метод, используемый большинством программного обеспечения GNU, то есть обеспечить собственную реализацию функции в случае, если она отсутствует в системных библиотеках. Я скомпилировал файл-5.11, GNU make 3.82, diffutils-2.8 для Android, передавая цепочки инструментов NDK / include / libs в autotools (./configure ...). Похоже, что эти программы содержат реализации большинства неосновных библиотечных функций, если стандартные библиотеки их не предоставляют (в данном случае Bionic).

Примечание. Я постараюсь создать статический glibc и обновлять ответ по мере успеха / неудачи.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
2

Если вы собираетесь использовать glibc вместо bionic, возможно, стоит изучить набор инструментов из дистрибутива arm-linux (совместимого поколения ядра), а не ndk. Это было бы особенно верно, если бы вы генерировали исполняемый файл командной строки. (Люди экспериментально внедрили среды chroot debian на устройствах Android вплоть до G1)

Для jni sub (который остается единственным официально одобренным средством для родного кода приложения) это могло бы стать немного «интересным» с любым набором инструментов, поскольку вы будете работать в процессе, который уже сопоставлен и постоянно использует bionic libc для поддержки виртуальной машины Dalvik. Предположительно, если вы статически связываете собственные зависимости библиотеки, вы не столкнетесь с конфликтами имен, но я ожидаю, что любой выбранный вами путь будет изучением внутренней работы, а не тем, что это обязательно плохо.

У вас должны быть няни? Я успешно построил проклятия для Android с ndk один раз. Также подумайте, серьезно ли это использует программа (то есть, действительно ли вы занимаетесь существенным форматированием текста?) Или просто используете ее для какой-то мелочи, потому что предполагается, что она доступна в целевых системах?

Error: User Rate Limit Exceededstackoverflow.com/questions/10798357/…

Похожие вопросы