Re: [boost] Problem with libs/system/src/error_code.cpp

From: Glenn Schrader (gschrad_at_[hidden])
Date: 2006-12-15 15:45:16

Beman Dawes wrote:
> 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? 
__SUNPRO_CC isn't defined but thats no doubt because I'm using gcc 4.1.1.
> And do you know if string.h comes with the 
> operating system or the compiler? 
string.h is in /usr/include
> 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?
>   
I've grepped the system headers and I can't find anything that seems 
related to the solaris version. 'uname -r' gets the version info from a 
call to sysinfo().

Thanks,

-glenn