Beman Dawes wrote:
James Dennett 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. A quick check on some development machines suggests that Solaris 9 does not. In areas in which I've worked, most systems have not upgraded to Solaris 10.
OK, thanks! The task now becomes how do we distinguish between systems with and without strerror_r?
Do you know if <cstring> and/or <string.h> come with Solaris or with the Sun compiler or perhaps separate from either?
I believe that <string.h> comes with the OS, and <cstring> comes with the compiler and wraps <string.h>, but I'll check... OK, that's almost it, <cstring> comes with the compiler and wraps /usr/include/iso/string_iso.h, and string.h also uses string_iso.h. In any case, the presence or absence of strerror_r depends on the OS with which the C library is bundled, not the compiler.
Boost's 1.34.0 regression test config_info is reporting:
Sun compiler version 0x580 ... sun =1 __SUNPRO_CC =0x580 __sun =1
If the header comes with the compiler, perhaps we can use the __SUNPRO_CC value to discriminate.
No, that doesn't work; you need to know the OS version for deployment to know what's available at runtime. You could assume by default that the user wishes to build code for the OS version on which they're compiling, but all too many places use Solaris 10 to build code they expect to run on older systems. -- James