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