программа завершает работу без ошибок при подключении библиотеки Boost

У меня проблема с подключением библиотеки Boost к моей кросс-скомпилированной программе на C ++.
Код, который я пишу, кросс-компилируется с CodeSourcery под Ubuntu 12.04 для целевой руки (Pandaboard, также Ubuntu 12.04).
Компиляция простых тестовых программ без библиотеки работает нормально, даже OpenCV со статическими библиотеками работает нормально.

Но вот проблема при связывании библиотек boost 1.52.0:

При кросс-компиляции с компоновкой расширенных библиотек (-lboost_thread -lboost_system) программа компилируется без ошибок, но при ее выполнении в target ничего не происходит.

Программа завершается без ошибок, как если бы она никогда не выполнялась.

При кросс-компиляции с CodeSourcery БЕЗ связывания библиотек наддува: все отлично работает на цели.
Скомпилировано локально с g ++: все также хорошо.

В целях тестирования я сократил свой код до следующих нескольких строк:
(ошибка появляется даже тогда, когда хроно-функция не используется. Различие только в ссылках)

main.cpp

#include <iostream>
using namespace std;

#include<boost/chrono.hpp>

int main(int argc, char* argv[]) {

cout << "!!!this test worked!!!" << endl;

return 0;
}

Команда компоновщика (вне затмения):

arm-none-linux-gnueabi-g++ -L/home/xy/arm-none-linux-gnueabi/lib -o "testARM" ./src/main.o -lpthread -lboost_thread -lboost_system

Буст-библиотеки были кросс-скомпилированы с помощью CodeSourcery arm-none-linux-gnueabi-g ++ после это руководство.
Я скопировал их все в целевой каталог в папку / usr / lib и добавил / usr / lib в PATH и в LD_LIBRARY_PATH.

Я пробовал удаленную отладку с помощью eclipse, и все то же самое: запуск программы .. программа завершена с 1.
Но ничего не случилось.

Он даже не печатает ошибку и не жалуется на то, что чего-то не хватает.
Так что теперь я не могу придумать ничего больше, что я мог бы Google, что я не пытался …

Не могли бы вы дать мне какие-нибудь подсказки, что я мог бы попытаться исправить это?

Спасибо заранее!


Обновить:

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


$ vi strace-testARM.log
22: 23: 56.511385 execve ("./ testARM", ["./testARM"], [/ * 17 vars * /]) = 0
22: 23: 56,512789 brk (0) = 0xfae000
22: 23: 56.512972 uname ({sys = "Linux", node = "panda", ...}) = 0
22: 23: 56.514010 доступ ("/ etc / ld.so.nohwcap", F_OK) = -1 ENOENT (такого файла или каталога нет)
22: 23: 56.514315 mmap2 (NULL, 8192, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0) = 0xb6f9b000
22: 23: 56.514498 access ("/ etc / ld.so.preload", R_OK) = -1 ENOENT (такого файла или каталога нет)
22: 23: 56.514742 open ("/ etc / ld.so.cache", O_RDONLY | O_CLOEXEC) = 3
22: 23: 56.514986 fstat64 (3, {st_mode = S_IFREG | 0644, st_size = 52288, ...}) = 0
22: 23: 56.515353 mmap2 (NULL, 52288, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f72000
22: 23: 56,515536 ​​закрыть (3) = 0
22: 23: 56.515688 доступ ("/ etc / ld.so.nohwcap", F_OK) = -1 ENOENT (такого файла или каталога нет)
22: 23: 56.515902 open ("/ lib / arm-linux-gnueabihf / libpthread.so.0", O_RDONLY | O_CLOEXEC) = 3
22: 23: 56.516207 читать (3, "\ 177ELF \ 1 \ 1 \ 1 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 3 \ 0 (\ 0 \ 1 \ 0 \ 0 \ 0 \ 5P \ 0 \ 0004 \ 0 \ 0 \ 0 "..., 512) = 512
22: 23: 56,516451 lseek (3, 66332, SEEK_SET) = 66332
22: 23: 56.516573 читать (3, "\ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 "..., 1400) = 1400
22: 23: 56,516787 lseek (3, 65924, SEEK_SET) = 65924
22: 23: 56.516909 читать (3, "A6 \ 0 \ 0 \ 0aeabi \ 0 \ 1, \ 0 \ 0 \ 0 \ 0057-A \ 0 \ 6 \ n \ 7A \ 10 \ 1 \ t \ 2 \ n \ 4 \ 22 "..., 55) = 55
22: 23: 56.517153 fstat64 (3, {st_mode = S_IFREG | 0755, st_size = 100802, ...}) = 0
22: 23: 56.517519 mmap2 (NULL, 107024, PROT_READ | PROT_EXEC, MAP_PRIVATE | MAP_DENYWRITE, 3, 0) = 0xb6f57000
22: 23: 56.517642 mprotect (0xb6f67000, 28672, PROT_NONE) = 0
22: 23: 56.517794 mmap2 (0xb6f6e000, 8192, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED | MAP_DENYWRITE, 3, 0xf) = 0xb6f6e000
22: 23: 56.517977 mmap2 (0xb6f70000, 4624, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED | MAP_ANONYMOUS, -1, 0) = 0xb6f70000
22: 23: 56,518160 закрыть (3) = 0
22: 23: 56.518313 доступ ("/ etc / ld.so.nohwcap", F_OK) = -1 ENOENT (такого файла или каталога нет)
22: 23: 56.518557 open ("/ lib / arm-linux-gnueabihf / tls / v7l / neon / vfp / libboost_thread.so.1.52.0", O_RDONLY | O_CLOEXEC) = -1 ENOENT (такого файла или каталога нет)
22: 23: 56.518832 stat64 ("/ lib / arm-linux-gnueabihf / tls / v7l / neon / vfp", 0xbea34ea8) = -1 ENOENT (такого файла или каталога нет)
22: 23: 56.519076 open ("/ lib / arm-linux-gnueabihf / tls / v7l / neon / libboost_thread.so.1.52.0", O_RDONLY | O_CLOEXEC) = -1 ENOENT (такого файла нет
... [много других каталогов с файлом не найден] ...
22: 23: 56.545382 stat64 ("/ usr / lib / neon / vfp", 0xbea34ea8) = -1 ENOENT (нет такого файла или каталога)
22: 23: 56.545565 open ("/ usr / lib / neon / libboost_thread.so.1.52.0", O_RDONLY | O_CLOEXEC) = -1 ENOENT (такого файла или каталога нет)
22: 23: 56.545748 stat64 ("/ usr / lib / neon", 0xbea34ea8) = -1 ENOENT (такого файла или каталога нет)
22: 23: 56.545932 open ("/ usr / lib / vfp / libboost_thread.so.1.52.0", O_RDONLY | O_CLOEXEC) = -1 ENOENT (такого файла или каталога нет)
22: 23: 56.546115 stat64 ("/ usr / lib / vfp", 0xbea34ea8) = -1 ENOENT (такого файла или каталога нет)
22: 23: 56.546298 open ("/ usr / lib / libboost_thread.so.1.52.0", O_RDONLY | O_CLOEXEC) = 3
22: 23: 56.546481 читать (3, "\ 177ELF \ 1 \ 1 \ 1 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 3 \ 0 (\ 0 \ 1 \ 0 \ 0 \ 0 \ 324 \ 331 \ 0 \ 0004 \ 0 \ 0 \ 0 "..., 512) = 512
22: 23: 56,546755 lseek (3, 121020, SEEK_SET) = 121020
22: 23: 56.546878 читать (3, "\ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 "..., 1200) = 1200
22: 23: 56.547091 lseek (3, 119052, SEEK_SET) = 119052
22: 23: 56,547213 читать (3, "A (\ 0 \ 0 \ 0aeabi \ 0 \ 1 \ 36 \ 0 \ 0 \ 0 \ 0055TE \ 0 \ 6 \ 4 \ 10 \ 1 \ t \ 1 \ 22 \ 4 \ 24 \ 1 \ 25 "..., 41) = 41
22: 23: 56.547396 exit_group (1) =?


Обновление 2:

Я компилирую свою программу на хосте Ubuntu, переношу файл на Pandaboard и выдаю следующие команды, предложенные @ShaunMarko:

`ldd testARM` =>  `not a dynamic executable`

`file testARM` => `testARM: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped`

`file libboost_thread.so.1.52.0` => `libboost_thread.so.1.52.0: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped`

Добавление -v -H к компиляции выражения g ++ я получаю:

... /xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/include/boost/utility/result_of.hpp

COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-v' '-H' '-MMD' '-MP' '-MF' 'main.d' '-MT' 'main.d' '-o' 'main.o' '-shared-libgcc' '-march=armv5te' '-mtls-dialect=gnu' '-funwind-tables' '-D' '__CS_SOURCERYGXX_MAJ__=2012' '-D' '__CS_SOURCERYGXX_MIN__=9' '-D' '__CS_SOURCERYGXX_REV__=64'
/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/as -v -march=armv5te -meabi=5 -o main.o /tmp/cceTwLmn.s
GNU assembler version 2.23.51 (arm-none-linux-gnueabi) using BFD version (Sourcery CodeBench Lite 2012.09-64) 2.23.51.20120829
COMPILER_PATH=/xy/CodeSourcery/bin/../libexec/gcc/arm-none-linux-gnueabi/4.7.2/:/xy/CodeSourcery/bin/../libexec/gcc/:/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/
LIBRARY_PATH=/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/:/xy/CodeSourcery/bin/../lib/gcc/:/xy/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/lib/:/xy/CodeSourcery/bin/../arm-none-linux-gnueabi/libc/lib/:/xy/CodeSourcery/bin/../arm-none-linux-gnueabi/libc/usr/lib/
COLLECT_GCC_OPTIONS='-O0' '-g3' '-Wall' '-c' '-fmessage-length=0' '-v' '-H' '-MMD' '-MP' '-MF' 'main.d' '-MT' 'main.d' '-o' 'main.o' '-shared-libgcc' '-march=armv5te' '-mtls-dialect=gnu' '-funwind-tables' '-D' '__CS_SOURCERYGXX_MAJ__=2012' '-D' '__CS_SOURCERYGXX_MIN__=9' '-D' '__CS_SOURCERYGXX_REV__=64'

**** Build Finished ****

(Это последняя часть, выше которой перечислены тонны включенных заголовков. Xy-Path — это то место, где CodeSourcery установлен в моем домашнем каталоге)

3

Решение

Общее правило для построения ARM-приложений (фактически оно должно быть справедливо для любой платформы)

Вы должны скомпилировать всю программу с тем же ABI и связать с совместимым набором библиотек.

В вашем случае последний элемент выглядит так /usr/lib/libboost_thread.so.1.52.0 и так как это также связано с вашим использованием, убедитесь, что libboost_thread соответствует тому на хосте, который вы кросс-компилируете.

22:23:56.546298 open("/usr/lib/libboost_thread.so.1.52.0", O_RDONLY|O_CLOEXEC) = 3
22:23:56.546481 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\324\331\0\0004\0\0\0"..., 512) = 512
22:23:56.546755 lseek(3, 121020, SEEK_SET) = 121020
22:23:56.546878 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1200) = 1200
22:23:56.547091 lseek(3, 119052, SEEK_SET) = 119052
22:23:56.547213 read(3, "A(\0\0\0aeabi\0\1\36\0\0\0\0055TE\0\6\4\10\1\t\1\22\4\24\1\25"..., 41) = 41
22:23:56.547396 exit_group(1)           = ?

С ARM В системах у вас может быть много вариантов библиотеки, таких как различные ABI или поддержка VFP / NEON, и получение готового набора инструментов может не совпадать с тем, на который вы нацелены по умолчанию, просто потому что это для ARM.

Обновить

Если вы проверите предыдущий журнал

22:23:56.515902 open("/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
22:23:56.516207 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\5P\0\0004\0\0\0"..., 512) = 512
22:23:56.516451 lseek(3, 66332, SEEK_SET) = 66332
22:23:56.516573 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1400) = 1400
22:23:56.516787 lseek(3, 65924, SEEK_SET) = 65924
22:23:56.516909 read(3, "A6\0\0\0aeabi\0\1,\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 55) = 55

Вы видите две вещи, во-первых, ваша система hf с пути. В прочитанных данных мы также видим 7-Aчто, вероятно, означает ARMv7-A по сравнению с 5TE что, вероятно, означает ARMv5TE из вашей библиотеки libboost_thread. Вы должны использовать readelf из вашего набора инструментов, чтобы получить информацию об эльфийских файлах вместо файловой утилиты.

Я бы попробовал скомпилировать форс с -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard и поместите полученный бинарный файл в `/ usr / lib / vfp.

Думаю читать ВФП вещи Сайт Debian может сильно помочь вам, и вы должны делать небольшие упражнения самостоятельно, вместо того, чтобы разбираться в процессе повышения, чтобы понять ситуацию.

3

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector