Re: [Boost-users] Boost 1.36 portability issues on FreeBSD 6.x?

Alexander Sack wrote:

On Thu, Oct 23, 2008 at 12:30 PM, Vladimir Prus wrote:

...

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?

Yes very much so. In fact I believe within the Linux community there are differences between the Debian folks and the Fedora/SuSE community about how to treat 32-bit binaries on 64-bit systems on how lib/rtld work. I do know you CAN'T do this on a FreeBSD machine. It will cause odd build failures for sure.

Well, if you can spec exactly what paths should be added under which circumstances, we surely can implement that.

Any suggestions about the trap stuff?

Sorry, no specific suggestions. Commenting them out in Boost code seems best.

...

...

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.

This wasn't a poke at Boost.Build which has helped me immensely (including you specifically, though you owe me a Trac account to file a bjam feature request!)

Oh, I do. Or rather I did -- see private email.

but I was confused on whether boost-build or boost-users or just boost is really the proper list for these questions (its a mix of a lot of different things).

...

...

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.

So since I'm the guinea pig, the answer is NO. LOL. So, how can I help? I got my FreeBSD 6.1 system to basically build. I'm still playing more with it and testing some stuff out (I know ASIO is gonna be interesting since ASIO on 6.1 specifically is broke but on 6.x it isn't).

Running regression tests is one approach.

The biggest challenge so far is the SIGNAL defines and what does 1.36 require from the underlying OS trap stuff? If I can get past this I'm very close to being able to update the official freebsd port which is a good thing (both for FreeBSD and Boosters).

My guess is that extra signal values can be just ignored. - Volodya