1

Boost (特に boost::thread と boost::asio) を使用するプロジェクトを VxWorks に移行しようとしています。

vxworks gnu コンパイラを使用してコンパイルするためのブーストが得られません。これを可能にすることを目的としたブースト トラックのパッチを見たので、これは問題にはならないと考えました。また、vxworks コンパイラは gnu ツール チェーンの一部であるため、次の指示に従うことができるはずです。クロス コンパイルのブースト ドキュメント。

私は ppc vxworks 用の Windows を構築しています。

ブースト ドキュメントで指定されているように user-config.jam ファイルを変更し、bjam に target-os=linux オプションを使用しましたが、bjam はコンパイルする前にハングしているように見えます。(-n オプションを使用して呼び出すことにより) bjam によって発行されたコマンドを詳しく調べると、boost::thread の win32 ファイルを使用してコンパイルしようとしていることがわかります。vxworks は pthread を使用するため、これは正しくありません。

私の bjam コマンド: .\bjam --with-thread toolset=gcc-ppc target-os=linuxgcc-ppc は、g++ppc vxworks クロス コンパイラを指すように user-config で設定されます。

私は何を間違っていますか？私は文書を文字どおりにフォローしたと信じています。

4

2 に答える 2

2

pthread ヘッダーではなく win32 ヘッダーを #include している場合、コンパイラが定義している一連のマクロとブースト ヘッダーがチェックしているマクロとの間に矛盾が生じる可能性があります。スマート ポインター ヘッダーでこのような問題が発生しました。これは、古いバージョンのブーストではチェックされ__ppcますが、コンパイラーが定義していました__ppc__(またはその逆は覚えていません)。

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

これにより、コンパイラによって事前定義されているマクロが表示されます。

VxWorks 用にブーストをコンパイルしようとしたことはありません。必要なヘッダーはほんのわずかだったからです。

于 2009-12-05T21:10:27.607 に答える
0

も追加してみてください

threadapi=pthread

あなたが言及したドキュメントはBoost.Build（スタンドアロンのビルドツール）用であり、上記のフラグはBoost.Threadライブラリに固有のものです。「ハング」とはどういう意味ですか? Boost ライブラリは巨大であるため、ビルド前に依存関係をスキャンするのに時間がかかることがあります。実際にハングした場合、デバッガーで bjam をキャッチしてバックトレースを生成できますか? また、出力のログが役立ちます。

于 2009-10-25T09:27:06.840 に答える