Кросс-компиляция Qt для Embedded Arm: libpthread.so.0 не найден

Я пытаюсь перекрестно скомпилировать Qt с помощью WebKit для встроенного устройства руки (процессор Freescale). У меня есть набор инструментов arm-none-linux-gnueabi.

Qt на самом деле скомпилирован, но я столкнулся с проблемами при попытке скомпилировать демо, в частности, WebKit, что мне и нужно.

Первая проблема, с которой я столкнулся, заключалась в том, что libjscore не был найден, что было ошибкой из-за того, как Qt обрабатывает статические сборки. Оказывается, вы можете скопировать библиотеку, и она работает, см. здесь.

Теперь компиляция снова прерывается, говоря, что не может найти libpthread.so.0, что может быть проблемой инструментальной цепочки, а не проблемой Qt.

При поиске в дереве каталогов в моей цепочке инструментов есть несколько libpthreads. Копия find | вывод команды grep libpthread приведен ниже для справки.

./arm-none-linux-gnueabi/sysroot/vfp/lib/libpthread-2.5.so
./arm-none-linux-gnueabi/sysroot/vfp/usr/lib/libpthread_nonshared.a
./arm-none-linux-gnueabi/sysroot/vfp/usr/lib/libpthread.a
./arm-none-linux-gnueabi/sysroot/vfp/usr/lib/libpthread.so_orig
./arm-none-linux-gnueabi/sysroot/vfp/usr/lib/libpthread.so
./arm-none-linux-gnueabi/sysroot/lib/libpthread-2.5.so
./arm-none-linux-gnueabi/sysroot/usr/lib/libpthread_nonshared.a
./arm-none-linux-gnueabi/sysroot/usr/lib/libpthread.a
./arm-none-linux-gnueabi/sysroot/usr/lib/libpthread.so_orig
./arm-none-linux-gnueabi/sysroot/usr/lib/libpthread.so

Значит, с компоновщиком что-то странное? Кроме того, что нужно сделать символической ссылкой для создания libpthread.so.0?

Примечание: _libpthread.so_orig_ и libpthread.so следуют этому исправить.

Любая помощь или предложения очень ценятся. Я уже два дня бьюсь головой о стену.

Спасибо


linker-errors embedded-linux arm qt cross-compiling
person Joey Yore    schedule 13.05.2011    source источник
comment
Кажется, у вас есть библиотеки. как правило, если есть несколько разделяемых библиотек (.so), они называются так: somelib.so.1 , somelib.so.2 , где иногда суффикс к .so также может быть именем версии. Поэтому я бы сказал, создайте символическую ссылку из libpthread.so.0 либо на libpthread.so, либо на libpthread.so_orig, либо на libpthread-2.5.so, возможно, все они будут работать, в противном случае просто свяжите новейшую версию libpthread.   -  person Abhijith    schedule 13.05.2011
comment
@abhijith - Спасибо за ваш ответ. Я добавил символическую ссылку из libpthread.so.0 в libpthread-2.5.so, и теперь компоновщик ломается на чем-то другом. Я получаю сообщение об ошибке: arm-none-linux-gnueabi/bin/ld: cannot find -lgcc_s. Где-то в дереве каталогов инструментальной цепочки есть libgcc_s. Любые идеи?   -  person Joey Yore    schedule 13.05.2011
comment
недостаточно, если это «где-то», оно должно быть в пути поиска вашей цепочки инструментов. вы можете добавить пути/каталоги поиска в свой компоновщик, используя опцию -L. Например, если вы хотите, чтобы компоновщик выполнял поиск файлов библиотеки в каталоге /usr/local/mydir, вы указываете эту опцию для компоновщика -L/usr/local/mydir.   -  person Abhijith    schedule 13.05.2011
comment
@abhijith - я смог правильно сослаться на него, но он не работает в другой библиотеке. Кажется, это общая тема здесь. Я собираюсь немного поиграть с ним, чтобы увидеть, смогу ли я сделать его счастливым. Я дам вам знать, если у меня возникнут какие-либо другие проблемы. Спасибо за вашу помощь.   -  person Joey Yore    schedule 13.05.2011
comment
Новая ошибка...warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking...Есть идеи, что я сейчас делаю неправильно?   -  person Joey Yore    schedule 13.05.2011
comment
это предупреждение, оно просто говорит вам, что вам понадобится dll позже. Это не остановит компиляцию и не станет проблемой позже, если только у вас нет glibc на устройстве.   -  person Abhijith    schedule 13.05.2011
comment
Вскоре после этого появились ошибки связывания. Весь вывод, кажется, связан с этим. Все неопределенные ссылки на _dlclose и подобные. В цепочке инструментов есть каталог glib. Может быть, мне нужно добавить каталог с -L, возможно?? В очередной раз благодарим за помощь.   -  person Joey Yore    schedule 14.05.2011
comment
да, если вы не уверены, что каталог ищет библиотеки, добавьте его с помощью параметра -L. Также помните, что важен порядок указания библиотек. Например, если liba зависит от libc, то предоставление этого компоновщику не удастся '-lc -la' , это правильный путь '-la -lc'. Для получения дополнительной информации см. linux.about.com/library/cmd/blcmdl1_ld.htm . Вам нужна опция --start-group --end-group   -  person Abhijith    schedule 14.05.2011
comment
только что проверено, все эти библиотеки уже находятся в пути и добавлены с -L. Я предполагаю, что есть вероятность, что порядок неправильный, но MakeFile генерируется с помощью Qt и qmake, поэтому я не думаю, что это так. Любые идеи, где начать искать дальше?   -  person Joey Yore    schedule 14.05.2011
comment
Трудно сказать, вам просто нужно убедиться, что все библиотеки есть, кроме этого не могу ничего придумать.   -  person Abhijith    schedule 14.05.2011
comment
да, я подумываю о перезапуске этого процесса в понедельник... думаю, нужно немного передохнуть... еще раз спасибо за вашу помощь   -  person Joey Yore    schedule 14.05.2011

Ответы (2)


arrow_upward
1
arrow_downward

В общем, вы должны убедиться, что цепочка инструментов, которую вы создали (или которая была создана для вас), находится точно на том же пути, по которому она была построена. Библиотеки (*.so *.a) также должны находиться по одному и тому же исходному пути. Это должно выглядеть так:

<path>/bin
<path>/usr/lib
<path>/lib

Эти папки не следует перемещать. Исполняемые файлы набора инструментов находятся в «bin», а библиотеки, которые он ищет, находятся в «../usr/lib и ../lib». Кроме того, <path> может быть каким-то образом жестко запрограммировано в ваши двоичные файлы gcc. Перемещение его, кажется, ломает вещи.

person sleeves    schedule 10.06.2011
comment
Запостил это с общего аккаунта и забыл обновить. Проблема действительно была связана с путем. На самом деле оказалось, что поставщик инструментов не включает все библиотеки, которые мне нужны, в набор инструментов, поэтому мне пришлось извлечь rootfs и связать библиотеки таким образом. Спасибо за ваш вклад! - person jyore; 11.07.2011
comment
@jyore Я столкнулся с той же проблемой. Не могли бы вы уточнить свое решение или опубликовать его как ответ? - person Hamzahfrq; 01.10.2014
comment
Человек это взрыв из прошлого. IIRC, я смонтировал файловую систему встроенных устройств на моем компьютере для сборки и указал цепочку инструментов на это монтирование, чтобы он мог использовать библиотеки системы/ядра. - person jyore; 02.10.2014

arrow_upward
-1
arrow_downward

Целью является Raspberry PI. Я копирую целевой каталог lib в myuserdirectory target /usr/lib в мой кросс-компилятор /usr/lib/ каталог target /lib мой кросскомпилятор /lib/ каталог

Я создаю две символические ссылки:

ln -s /yourcrosscompilerusrlibdirectory /usr/lib/arm-linux-gnueabihf
ln -s /yourcrosscompilerusrdirectory /lib/arm-linux-gnueabihf

и это работает для меня, libpthread находится в /yourcrosscompilerusrlibdirectory

person amelinux    schedule 11.09.2016