VxWorks 6.4 交叉编译 Boost 1.40
我正在尝试将使用Boost（特别是boost::thread 和boost::asio）的项目迁移到VxWorks。
我无法使用 vxworks gnu 编译器进行编译。我认为这不会成为问题，因为我在 boost trac 上看到了旨在使这成为可能的补丁，并且由于 vxworks 编译器是 gnu 工具链的一部分，我应该能够遵循用于交叉编译的boost 文档。
我正在 Windows 上构建 ppc vxworks。
我按照 boost 文档中的指定更改了 user-config.jam 文件，并对 bjam 使用了 target-os=linux 选项，但 bjam 似乎在编译之前挂起。仔细检查 bjam 发出的命令（通过使用 -n 选项调用它）发现它正在尝试使用 boost::thread 的 win32 文件进行编译。这是不对的，因为 vxworks 使用 pthreads。
我的 bjam 命令： .\bjam --with-thread toolset=gcc-ppc target-os=linux gcc-ppc 在用户配置中设置为指向 g++ppc vxworks 交叉编译器。
我做错了什么？我相信我已经严格按照文档进行操作。
I'm trying to migrate a project which uses Boost (particularly boost::thread and boost::asio) to VxWorks.
I can't get boost to compile using the vxworks gnu compiler. I figured that this wasn't going to be an issue as I'd seen patches on the boost trac that purport to make this possible, and since the vxworks compiler is part of the gnu tool chain I should be able to follow the directions in the boost docs for cross compilation.
I'm building on windows for a ppc vxworks.
I changed the user-config.jam file as specified in the boost docs, and used the target-os=linux option to bjam, but bjam appears to hang before it can compile. Closer inspection of the commands issued by bjam (by invoking it using the -n option) reveal that it's trying to compile with boost::thread's win32 files. This can't be right, as vxworks uses pthreads.
My bjam command: .\bjam --with-thread toolset=gcc-ppc target-os=linux gcc-ppc is set in user-config to point to the g++ppc vxworks cross compiler.
What am I doing wrong? I believe I have followed the docs to the letter.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果它是 #include win32 标头而不是 pthread 标头，则编译器定义的宏集与 boost 标头正在检查的宏之间可能存在差异。我遇到了与智能指针头类似的问题，在旧版本的 boost 中，它会检查
__ppc但我的编译器定义了__ppc__（反之亦然，不能记住）。这将显示编译器预定义了哪些宏。
我从未尝试为 VxWorks 编译 boost，因为我只需要一些标头。
If it's #including win32 headers instead of the pthread ones, there could be a discrepancy between the set of macros your compiler is defining and the macros the boost headers are checking for. I had a problem like that with the smart pointer headers, which in an older version of boost would check for
__ppcbut my compiler defined__ppc__(or vice versa, can't remember).That will show you what macros are predefined by your compiler.
I never tried to compile boost for VxWorks, since I only needed a few of the headers.
还尝试添加
您提到的文档适用于 Boost.Build——这是独立的构建工具——而上面的标志是 Boost.Thread 库特有的。你说的“挂”是什么意思？由于 Boost 库非常庞大，因此有时在构建之前需要花费大量时间来扫描依赖项。
如果它确实挂起，您可以在调试器中捕获 bjam 并生成回溯吗？此外，任何输出的日志都会有所帮助。
Try also adding
The documentation you mention is for Boost.Build -- which is standalone build tool -- and the above flag is something specific to Boost.Thread library. What do you mean by "hang"? Because Boost libraries are huge, it sometimes take a lot of time to scan dependencies prior to build.
If it actually hangs, can you catch bjam in a debugger and produce a backtrace? Also, log of any output will help.