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

Subject: Re: [Boost-users] Boost 1.36 portability issues on FreeBSD 6.x?
From: Alexander Sack (pisymbol_at_[hidden])
Date: 2008-10-23 12:40:45

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.

Any suggestions about the trap stuff?

>> 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!) 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).

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

Thanks everybody,

-aps