Glenn Schrader wrote:
Beman Dawes wrote:
Glenn Schrader wrote:
I had a problem compiling boost on a sparc solaris 2.8 platform. After a bit of digging the change below (notice the end of the #if). The code in the #else calls strerror_r but solaris doesn't have it.
Hum... See http://docs.sun.com/app/docs/doc/816-5168/6mbb3hrti?a=view
It looks like Solaris 10 at least does have strerror_r.
Are you really using 2.8? How old is that?
Older than I would like but I don't have a choice. We use some VME based real-time systems that have a sparc based SBC running solaris 2.8. There are driver compatibility issues for 3rd party boards that make us stick with this configuration.
Makes sense.
Could the problem really be that error_code.cpp is including <cstring>, but really needs to include <string.h>?
No, its not in string.h either. Just to double check; I couldn't find strerror_r by grepping all of the headers under /etc. There is also no man page for strerror_r.
That gibes with James Dennett's report that it doesn't appear until Solaris 10.
Given that Sun does support strerror_r on some versions, I'd like to only fallback to strerror when absolutely necessary
That makes sense. I listed the macros that gcc was predefining using 'cpp -dM /dev/null' and there doesn't seem to be a macro containing the solaris version. I haven't looked at bjam very much but could it run some autoconf-like test cases to determine the correct function and headers to use?
Boost.Config may be able to help, but first, what value is __SUNPRO_CC set to in your environment? And do you know if string.h comes with the operating system or the compiler? It would be misleading to base choice on a compiler macro if in fact the header involved ships with the OS. Do you know if there is a way to discover the version of the operating system on Solaris? Thanks, --Beman Thanks, --Beman