
Alexander Sack wrote:
Hello:
I have a FreeBSD 6.1 amd64 box and I'm running into various issues building boost on my platform. In no particular order:
- libboost_prg_exec_monitor checks for a lot of optional signal codes (execution_monitor.ipp file) that FreeBSD 6.1 does not support AND FreeBSD 7 supports somewhat. I'm talking about the XSI codes for SIGCHLD, SIGILL, etc. in my /usr/include/sys/signal.h (amd64 tree but is also a problem on my x86 branch):
e.g. #define ILL_ILLOPC 1 /* [XSI] illegal opcode */ #define ILL_ILLTRP 2 /* [XSI] illegal trap */ #define ILL_PRVOPC 3 /* [XSI] privileged opcode */ #define ILL_ILLOPN 4 /* [XSI] illegal operand -NOTIMP */ #define ILL_ILLADR 5 /* [XSI] illegal addressing mode -NOTIMP */ #define ILL_PRVREG 6 /* [XSI] privileged register -NOTIMP */ #define ILL_COPROC 7 /* [XSI] coprocessor error -NOTIMP */ #define ILL_BADSTK 8 /* [XSI] internal stack error -NOTIMP */ #define CLD_EXITED
What's the best thing to do here? I've actually compiled against FreeBSD 7's signal.h just to get me through this but the fact is the kernel (trap.c) does not set these codes. Will this cause Boost to crap out on me during runtime? If so, is there a workaround since this seems like a real bug in portability?
- SIGPOLL is not defined, its SIGIO (I can work around this)
- The Boost build when doing its standard tests sets up the LD_LIBRARY_PATH on my box as:
LD_LIBRARY_PATH=/usr/bin:/usr/lib:/usr/lib32:/usr/lib64
- ICU for FreeBSD is in /usr/include/local which causes the build.jam stuff to miss autodetecting it
On a 64-bit machine, adding /usr/lib32 BREAKS not only the test but most natively compiled binaries - I had to move /usr/lib32 and rename it for some of the tests to work (like boost_std_no_locale) etc.
Do you know if this is an area where freebsd differs from linux?
I started a thread on Boost-Build but got no replies.
I guess that's because your initial post was not about Boost.Build, but about the signal names, so nobody at Boost.Build mailing list felt qualified to say anything.
I'm just wondering how portable the latest release of Boost is on FreeBSD?
I don't think we have any *BSD testing, so we don't know for sure. - Volodya