Boost 1.36 portability issues on FreeBSD 6.x?
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. I started a thread on Boost-Build but got no replies. I'm just wondering how portable the latest release of Boost is on FreeBSD? Btw, there are several files I had to patch within boost to even get it to build relatively far (and I haven't tried python support just yet). The current BSD port is 1.34 and has been that for a long time (there was a 1.35 release at some point in beta testing) but I would like to update it to 1.36 but need some guidance on the above. Any guidance would be much appreciated... Thanks! -aps
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
On Thu, Oct 23, 2008 at 12:30 PM, Vladimir Prus <vladimir@codesourcery.com> 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
Alexander Sack wrote:
On Thu, Oct 23, 2008 at 12:30 PM, Vladimir Prus <vladimir@codesourcery.com> 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
On Thu, Oct 23, 2008 at 1:55 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Alexander Sack wrote:
On Thu, Oct 23, 2008 at 12:30 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Alexander Sack wrote: 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.
Ok, will try to come up with something.
Any suggestions about the trap stuff?
Sorry, no specific suggestions. Commenting them out in Boost code seems best.
Hmmm....alright...do you know what the ramifications are? My guess is specific traps won't be thrown under boost. Of course, for FreeBSD 7, I think we might be ok.
Oh, I do. Or rather I did -- see private email.
Thanks, much appreciated! I know you're busy!
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.
Ok, how do I do that? i.e. do you have a certain set of tests in mind?
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.
That's mine too at this point so I will attempt to come up with some patches and post for the official tree. It shouldn't be this hard to build Boost on FreeBSD (considering BSD is a standard UNIX distro). -aps
AMDG Alexander Sack wrote:
Running regression tests is one approach.
Ok, how do I do that? i.e. do you have a certain set of tests in mind?
http://www.boost.org/development/running_regression_tests.html In Christ, Steven Watanabe
On Thu, Oct 23, 2008 at 3:11 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Alexander Sack wrote:
Running regression tests is one approach.
Ok, how do I do that? i.e. do you have a certain set of tests in mind?
http://www.boost.org/development/running_regression_tests.html
In Christ, Steven Watanabe
Thanks Steven. Its is AMAZING how I miss stuff on the boost webpages!! Arrgh... :D -aps
Alexander Sack wrote:
On Thu, Oct 23, 2008 at 1:55 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Alexander Sack wrote:
On Thu, Oct 23, 2008 at 12:30 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Alexander Sack wrote: 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.
Ok, will try to come up with something.
Any suggestions about the trap stuff?
Sorry, no specific suggestions. Commenting them out in Boost code seems best.
Hmmm....alright...do you know what the ramifications are? My guess is specific traps won't be thrown under boost. Of course, for FreeBSD 7, I think we might be ok.
It's been a long time since I've used Boost.Test, but I believe the only problem is that if kernel delivers a signal Boost.Test does not know about, Boost.Test won't be able to tell which signal it was. Now, if signal.h does not define some signal it most likely means the kernel will never deliver it, so you're safe.
My guess is that extra signal values can be just ignored.
That's mine too at this point so I will attempt to come up with some patches and post for the official tree. It shouldn't be this hard to build Boost on FreeBSD (considering BSD is a standard UNIX distro).
Is there "standard UNIX"? :-) - Volodya
On Thu, Oct 23, 2008 at 3:36 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Alexander Sack wrote:
On Thu, Oct 23, 2008 at 1:55 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Alexander Sack wrote:
On Thu, Oct 23, 2008 at 12:30 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Alexander Sack wrote: 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.
Ok, will try to come up with something.
Any suggestions about the trap stuff?
Sorry, no specific suggestions. Commenting them out in Boost code seems best.
Hmmm....alright...do you know what the ramifications are? My guess is specific traps won't be thrown under boost. Of course, for FreeBSD 7, I think we might be ok.
It's been a long time since I've used Boost.Test, but I believe the only problem is that if kernel delivers a signal Boost.Test does not know about, Boost.Test won't be able to tell which signal it was. Now, if signal.h does not define some signal it most likely means the kernel will never deliver it, so you're safe.
LOL, that's what I'm banking on!!! :D I'll have some patches to get this to go on FreeBSD.
Is there "standard UNIX"? :-)
No but its not spelled L-I-N-U-X despite what many would have you believe (nothing against it either)! :D Uggghhhh...point taken but still FreeBSD is pretty popular these days. Considering we've got case statements for other less popular UNIX variants, I'm kinda shocked Boost doesn't build out of the box on a BSD machine. -aps
participants (3)
-
Alexander Sack -
Steven Watanabe -
Vladimir Prus