linux — проблемы компиляции c ++ для встроенной системы

У меня есть несколько связанных вопросов о моих проблемах с компиляцией для встроенной системы. Мои вопросы не только о том, КАК что-то сделать, но больше о ПОЧЕМУ, потому что у меня есть решения для моих проблем (но, может быть, есть и лучшие?), Но я понятия не имею, почему некоторые вещи работают в некоторых условиях и не работают в другие. Я уже провел некоторое время с этим, но до вчерашнего дня я делал что-то немного слепо, с пробами и ошибками, не зная, что я делаю. Время остановить это! Пожалуйста помоги.

сценарий

Я хочу разработать приложение для процессора Zilq ARM от Xilinx на Zedboard. Приложение будет включать в себя многопоточность, некоторые манипуляции с аудио и httpserver. Поэтому мне понадобятся библиотеки pthread, alsa, sndfile и microhttpd. Я создал rootfs с Yocto. В оригинальном файле conf.local я добавил / изменил эти строки:

BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"MACHINE ?= "zedboard-zynq7"PACKAGE_CLASSES ?= "package_deb"EXTRA_IMAGE_FEATURES = "debug-tweaks eclipse-debug"IMAGE_INSTALL_append = "libgcc alsa-utils mpg123 libstdc++ sthttpd libmicrohttpd libsndfile1"LICENSE_FLAGS_WHITELIST = "commercial_mpg123"

Мне также пришлось добавить несколько дополнительных слоев в bblayers.conf (и, конечно же, загрузить их):

meta-xilinx
meta-multimedia (from meta-openembedded)
meta-oe         (from meta-openembedded)
meta-webserver  (from meta-openembedded)

Наконец, я создал core-image-minimal с помощью bitbake.

Это вместе с ядром Linux и другими компонентами, скомпилированными отдельно, загружается и работает нормально.

1. Простое приложение с этим rootfs

Это приложение для Zynq, поэтому я использую XSDK, который является SDK от Xilinx на основе Eclipse. Я создал новый проект приложения. В диалоговом окне я выбрал Linux в качестве платформы, C ++ в качестве языка и указал путь к моим распакованным rootfs (точно тот, который загружается системой через NFS). Мой путь rootfs /home/stas/ZedboardPetalinuxFS (это не Petalinux, я просто использовал его, и это имя папки остается прежним). Это устанавливает правильные пути для поиска библиотеки и заголовков в rootfs.
Я начал с чего-то очень простого:

#include <pthread.h>

int main()
{
int i;
i = 1;
return 0;
}

Я также добавил библиотеку pthread для компоновщика (в настройках Eclipse). Связывание команды на этом этапе:

arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" -o "test.elf"  ./src/main.o   -lpthread

На данный момент он компилируется. Но это останавливается, когда я добавляю библиотеку sndfile

#include <sndfile.h>

Это разумно, потому что у этого rootfs не все заголовки. Мне нужно добавить еще один путь для поиска заголовков. Поэтому я добавил путь в папку yocto tmp, в которой есть все заголовки, необходимые для сборки rootfs. После того, как я его добавлю, он снова успешно скомпилируется. Но проблемы начались, когда я добавил библиотеку sndfile для линковки. Вот связь команды и ошибки:

arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" -o "test.elf"  ./src/main.o   -lpthread -lsndfile
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lsndfile

Я посмотрел на usr / lib, чтобы проверить, есть ли libsndfile.so, и нашел только libsndfile.so.1 и ibsndfile.so.1.27. Но это также относится и к pthread, и компоновщик не жалуется на это. Я решил создать libsndfile.so вручную (я связал его с libsndfile.so.1). Линкер перестал жаловаться на это, но начал жаловаться на его зависимость. Поэтому я также создал файлы .so для всех зависимостей и их зависимостей и добавил их для связывания. Тогда это удалось. В конце команда связывания выглядела так:

arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" -o "test.elf"  ./src/main.o   -lpthread -lvorbisenc -lvorbis -logg -lFLAC -lsndfile

Итак, первый вопрос — почему мне не нужен .so файл для pthread, но он нужен для всех остальных библиотек? Или более общий — когда мне нужен файл .so, а когда файла .so.X достаточно?

2. Простое приложение — другой подход

После первой попытки я подумал, что мне следует создать другое изображение, на этот раз более подходящее для разработки. К счастью, в Yocto это довольно просто — мне просто нужно было изменить одну строку:

EXTRA_IMAGE_FEATURES = "debug-tweaks eclipse-debug dev-pkgs"

Опция dev-pkgs добавляет пакеты -dev для всех установленных пакетов.
Так что теперь у меня есть rootfs со всеми необходимыми заголовками и .so файлы, указывающие, где они должны.
Перед компиляцией я удалил ненужный путь «Включить», оставив только один из корневых файлов, и удалил все библиотеки, кроме pthread и sndfile. Но тогда я получаю новые ошибки:

arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" -o "test.elf"  ./src/main.o   -lsndfile -lpthread
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/libpthread.so.0
makefile:48: polecenia dla obiektu 'test.elf' nie powiodły się (commands for ‘test.elf’ did not succeed)
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find /usr/lib/libpthread_nonshared.a

Я заметил, что он ищет библиотеки в моей корневой папке. Быстрый поиск в Google (и SO 🙂 сказал мне, что я должен установить переменную –sysroot. Таким образом, я добавил его в опцию Eclipse (в разделе Miscelenious в опциях Linker) следующим образом:

--sysroot=/home/stas/ZedboardPetalinuxFS

Теперь команда компоновщика выглядит так:

arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" --sysroot=/home/stas/ZedboardPetalinuxFS -o "test.elf"  ./src/main.o   -lsndfile -lpthread

И все получится! Я также написал простой пример, который использует pthreads и sndfile, и это тоже сработало. Но почему? Это приводит меня ко второму вопросу:
Зачем мне нужна опция —sysroot в этом случае? Когда мне нужно использовать эту опцию в целом? И почему в этот раз мне не пришлось добавлять все зависимости в команду связывания?

3. Еще одна идея

На данный момент у меня появилась идея, чтобы проверить, что произойдет, если я добавлю --sysroot возможность иметь rootfs, заполненную старым, не разработанным образом. Но это дало мне новые ошибки:

arm-linux-gnueabihf-g++ -L"/home/stas/ZedboardPetalinuxFS/usr/lib" -L"/home/stas/ZedboardPetalinuxFS/lib" --sysroot=/home/stas/ZedboardPetalinuxFS -o "test.elf"  ./src/main.o   -lpthread -lvorbisenc -lvorbis -logg -lFLAC -lsndfile
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find crt1.o: No such file or directory
makefile:48: polecenia dla obiektu 'test.elf' nie powiodły się
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find crti.o: No such file or directory
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lpthread
/opt/Xilinx/SDK/2016.4/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/5.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lm

Итак, третий вопрос — что означают эти ошибки?

Большое спасибо заранее!