Кросс-компиляция Boost 1.40 для VxWorks 6.4

Question

Я пытаюсь перенести проект, использующий Boost (особенно boost :: thread и boost :: asio), на VxWorks.

Я не могу ускориться при компиляции с использованием компилятора vxworks gnu. Я подумал, что это не будет проблемой, так как я видел патчи на Boost Trac, предназначенные для того, чтобы сделать это возможным, и, поскольку компилятор vxworks является частью цепочки инструментов gnu, я должен иметь возможность следовать указаниям документация для повышения для кросс-компиляции.

Я строю на Windows для ПК vxworks.

Я изменил файл user-config.jam, как указано в документах boost, и использовал параметр target-os = linux для bjam, но bjam, кажется, зависает, прежде чем его можно будет скомпилировать. Более тщательный анализ команд, выданных bjam (вызывая его с помощью опции -n), показывает, что он пытается скомпилировать файлы win32 boost :: thread. Это не может быть правильно, так как vxworks использует pthreads.

Моя команда bjam: .\bjam --with-thread toolset=gcc-ppc target-os=linux gcc-ppc установлен в user-config для указания на кросс-компилятор g ++ ppc vxworks.

Что я делаю не так? Я думаю, что я следовал документам к письму.

Answer 1

Если это #, включая заголовки win32 вместо заголовков pthread, может быть несоответствие между набором макросов, которые определяет ваш компилятор, и макросами, которые проверяют заголовки наддува. У меня была такая проблема с заголовками интеллектуальных указателей, которые в более старой версии boost проверяли бы __ppc, но мой компилятор определил __ppc__ (или наоборот, не помню).

touch empty.cpp
ccppc -dD -E empty.cpp

Это покажет вам, какие макросы предопределены вашим компилятором.

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

Answer 2

Попробуйте также добавить

threadapi=pthread

Документация, которую вы упоминаете, относится к Boost.Build - автономному инструменту сборки - и указанный выше флаг относится к библиотеке Boost.Thread Что вы подразумеваете под "зависать"? Поскольку библиотеки Boost огромны, иногда для сканирования зависимостей требуется много времени перед сборкой. Если он действительно зависает, можете ли вы отловить bjam в отладчике и произвести обратную трассировку? Также поможет лог любого вывода.