From: Glenn Schrader (gschrad_at_[hidden])
Date: 2006-12-15 09:55:03
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.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost