glibc не найден при включении оптимизаций компилятора

Question

Я перекрестно компилирую общую библиотеку (miniweb) для чернового устройства beaglebone. Когда я компилирую без оптимизации, у меня нет проблем. Однако, если я компилирую с любыми оптимизациями (т.е. -O3) я получаю следующее при попытке запустить мою программу:

./myprogram: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.15' not found (required by /usr/lib/libminiweb.so) 

Моего первый вопрос, почему позволят оптимизации внезапно привести свою программу в зависимости от этой библиотеки? Является ли контент статически включенным в библиотеку, когда оптимизация отключена?

Как определить версию библиотеки c, которую использует мой кросс-компилятор? Я запустить следующую команду ldd --version на обеих системах:

рабочий стол:

$ ldd --version 
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.6) 2.19 
Copyright (C) 2014 Free Software Foundation, Inc. 

beaglebone:

ldd --version 
ldd (Debian EGLIBC 2.13-38+deb7u1) 2.13 
Copyright (C) 2011 Free Software Foundation, Inc. 

Очевидно, что библиотека у меня устарел, но как вы можете увидеть мои системные отчеты используя eglibc вместо glibc?

Как моя кросс-скомпилированная библиотека может зависеть от glibc? Возможно, работает ldd на моем рабочем столе, не является точным отражением библиотек, используемых моим кросс-компилятором?

Как я могу найти, какую библиотеку c использует мой кросс-компилятор?

Answer 1

Мой первый вопрос, почему включение оптимизации может привести к тому, что моя программа будет зависеть от этой библиотеки?

Ваша программа является зависит от libc.so.6 с и без оптимизаций. Вы можете проверить это, выполнив ldd ./myprogram в целевой системе.

Что происходит в том, что ваша программа с оптимизацией становится зависимой от более поздней версии от libc.so.6, затем той, которую вы установили.

Предположим заголовочный файл содержит следующее:

inline int foo() { return bar() + 1; } 

Далее предположим, что ваша программа вызывает foo. Без оптимизаций foo будет не быть встроенным, и ваша программа будет зависеть от foo.

С оптимизациями, fooбудет быть встраиваемым, и ваша программа больше не будет зависеть от foo, но будет зависеть от bar вместо этого.

Если в статическое время ссылки вы связываете библиотеку lifoobar.so, которая содержит как foo, так и bar, ваша ссылка будет успешна с оптимизацией или без нее.

Если в динамическое время связи (т.во время выполнения) используется другая версия libfoobar.so, которая обеспечивает foo, но не предоставляет bar, тогда неоптимизированная программа будет работать нормально, но оптимизированная программа не сработает с bar не найдена.

Это то, что происходит с вами, только вместо bar вы используете версионируются символ some-libc-func@GLIBC_2.15 и что силы вашей программы зависит от версии GLIBC_2.15, которая является то, что отсутствует от цели.

Содержимое, статически включенное в библиотеку, когда оптимизация отключена?

No.

Как определить версию библиотеки С, мой кросс-компилятор использует?

Это libc-2.15.so или более поздняя версия. Вы должны посмотреть в своем каталоге кросс-компилятора.

рабочий стол: $ ldd --version

Что у вас на рабочем столе является совершенно неуместными. Важно то, что использует ваш кросс-компилятор.

Как моя кросс-скомпилированная библиотека может зависеть от glibc?

Вашего кросс-компилятор обеспечивает свою собственную версию из GLIBC, и ваш крест скомпилированных двоичные зависит от этого GLIBC.

Другими словами, есть 3 различные версии GLIBC здесь:

1. один на рабочем столе (не имеет значения)
2. один ваш кросс-компилятор использует для связи ваш бинарный файл
3. один на вашей целевой (beaglebone) системе.

Мы знаем, что (2), по меньшей мере, GLIBC-2.15 от сообщения об ошибке, и мы знаем, что (3) является GLIBC-2.13 (который слишком стар).

Как я могу найти, какую библиотеку c использует мой кросс-компилятор?

Ищите его в своем каталоге установки кросс-компилятора.

Вы также можете попросить компоновщика распечатать его для вас:

echo "int main() { return 0; }" | /path/to/cross-gcc -Wl,-t -xc -