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.
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.
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?
Is this the correct place to send this sort of thing or is there a more formal bug tracking system?
This is fine. It really helps, however, to include the library name ("[system]" in this case) in square brackets at the start of the subject line. That helps to direct the posting to the right Boost developer.
Thanks,
--Beman
OK. Thanks, --glenn
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost