Boost logo

Boost Users :

Subject: Re: [Boost-users] Boost 1.36 portability issues on FreeBSD 6.x?
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-10-23 13:55:04

Alexander Sack wrote:

> On Thu, Oct 23, 2008 at 12:30 PM, Vladimir Prus
> <vladimir_at_[hidden]> 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

>>> 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

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at