Problem with libs/system/src/error_code.cpp
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. Is this the correct place to send this sort of thing or is there a more formal bug tracking system? Thanks, -glenn BEFORE: std::string errno_md( const error_code & ec ) { # if defined(BOOST_WINDOWS_API) || defined(__hpux) || (defined(__linux) && !defined(__USE_XOPEN2K)) const char * c_str = std::strerror( ec.value() ); return std::string( c_str ? c_str : "EINVAL" ); # else char buf[64]; AFTER: std::string errno_md( const error_code & ec ) { # if defined(BOOST_WINDOWS_API) || defined(__hpux) || (defined(__linux) && !defined(__USE_XOPEN2K)) || defined(__sun) const char * c_str = std::strerror( ec.value() ); return std::string( c_str ? c_str : "EINVAL" ); # else char buf[64];
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? Could the problem really be that error_code.cpp is including <cstring>, but really needs to include <string.h>? Given that Sun does support strerror_r on some versions, I'd like to only fallback to strerror when absolutely necessary.
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
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.
Are you really using 2.8? How old is that?
I can't speak for Glenn, but many places are using 2.8 or earlier versions; Sun tends to provide support for quite some time. -- James
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? 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. Thanks, --Beman
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
From: Oliver.Kowalke@qimonda.com
??? wrote:
No, that doesn't work; you need to know the OS version for deployment to know what's available at runtime.
Autoconfig could help in this place - could this be integrated in the boost build process?
I don't think Autoconfig /does/ help. What ??? said (I have forgotten their name, and you didn't attribute the quote), is that people build on Solaris 10 (which has strerror_r) and then expect to be able to run on Solaris 2 (which doesn't). It seems to me that the only possible solution to that, is a define which forces the use of strerror. We don't want to use strerror unless we have to (because of thread safety), and the person building the code is the only person who can know whether they need the capability to deploy on Solaris 2. Hmm. Maybe boost should use strerror_r always, and then tell people how to write their own version if the OS doesn't provide it. (Grab a lock, call strerror, copy result to passed in buffer, release lock - absolutely safe against multithreaded calls to strerror_r, and there's a good chance that other calls to strerror will work) -- Martin Bonner Pi Shurlok, Milton Hall, Ely Rd, Cambridge, CB24 6WZ, ENGLAND +44 (0) 1223 203894
From: Martin Bonner
I don't think Autoconfig /does/ help.
I'm using autoconfig in order to check if some OS features are available. Autoconfigure gives you the os name, version and relase. It is a great help for multiplatform development! For instance I test with autoconfigure if a given platform supports MSG_NOSIGNAL flag in the system call sendmsg. What ??? said (I have
forgotten their name, and you didn't attribute the quote), is that people build on Solaris 10 (which has strerror_r) and then expect to be able to run on Solaris 2 (which doesn't).
On HP/UX for instance the patch level of the system is also important. So only on teyting for os version/relase is not sufficient.
It seems to me that the only possible solution to that, is a define which forces the use of strerror. We don't want to use strerror unless we have to (because of thread safety), and the person building the code is the only person who can know whether they need the capability to deploy on Solaris 2.
With aoutconfig the build process can check if strerror_r is avaliable and provide strerror as fall back.
Hmm. Maybe boost should use strerror_r always, and then tell people how to write their own version if the OS doesn't provide it. (Grab a lock, call strerror, copy result to passed in buffer, release lock - absolutely safe against multithreaded calls to strerror_r, and there's a good chance that other calls to strerror will work)
Bad idea. Oliver
From: Oliver.Kowalke@qimonda.com
With autoconfig the build process can check if strerror_r is avaliable and provide strerror as fall back.
Autoconfig can check if strerror_r is available ON THE BUILD MACHINE. It CANNOT tell whether it will be available on the target machines. -- Martin Bonner Pi Shurlok, Milton Hall, Ely Rd, Cambridge, CB24 6WZ, ENGLAND +44 (0) 1223 203894
On Mon, 18 Dec 2006 10:51:52 -0000, "Martin Bonner" <martin.bonner@pitechnology.com> said:
From: Oliver.Kowalke@qimonda.com
With autoconfig the build process can check if strerror_r is avaliable and provide strerror as fall back.
Autoconfig can check if strerror_r is available ON THE BUILD MACHINE. It CANNOT tell whether it will be available on the target machines.
Unless I'm missing something, isn't this discussion only about Solaris? The Solaris man pages (I checked 7 and 10) say that strerror is MT-safe, so wouldn't it be simpler to always use that function when building for that platform? Solaris 7: http://docs.sun.com/app/docs/doc/805-3175/6j31empgq?a=view Solaris 10: http://docs.sun.com/app/docs/doc/816-5168/6mbb3hrti?a=view Cheers, Chris
Christopher Kohlhoff wrote:
On Mon, 18 Dec 2006 10:51:52 -0000, "Martin Bonner" <martin.bonner@pitechnology.com> said:
From: Oliver.Kowalke@qimonda.com
With autoconfig the build process can check if strerror_r is avaliable and provide strerror as fall back. Autoconfig can check if strerror_r is available ON THE BUILD MACHINE. It CANNOT tell whether it will be available on the target machines.
Unless I'm missing something, isn't this discussion only about Solaris? The Solaris man pages (I checked 7 and 10) say that strerror is MT-safe, so wouldn't it be simpler to always use that function when building for that platform?
Solaris 7: http://docs.sun.com/app/docs/doc/805-3175/6j31empgq?a=view Solaris 10: http://docs.sun.com/app/docs/doc/816-5168/6mbb3hrti?a=view
According to other posts the same is also true of HP-UX. So I've changed the code to always use strerror on Sun and HP-UX. For Linux, I've changed the code to: (defined(__linux) && (!defined(__USE_XOPEN2K) || defined(BOOST_SYSTEM_USE_STRERROR))) My Linux testing machine is in pieces at the moment, so I could not test before committing, and I don't have access to a Sun or HP-UX machine in any case. So be warned the fix may have typos or other problems. Thanks for digging into this, --Beman
From : Beman Dawes
(defined(__linux) && (!defined(__USE_XOPEN2K) || defined(BOOST_SYSTEM_USE_STRERROR)))
Would autocnf be integrated into boost build process we could prevent such ugly Preprocessor defines. We could write: #ifdef HAS_STRERROR_R ... #else ... #endif The preprocessor define HAS_STRERROR_R could be avaluated by the m4 macro: AC_MSG_CHECKING([for strerror_r support]) AC_CACHE_VAL(ac_cv_strerror_r, AC_TRY_RUN([ # include <errno.h> # include <string.h> # include <stdlib.h> main() { strerror_r(EINTR, 0, 0); exit( 0); }], ac_cv_strerror_r=yes, ac_cv_strerror_r=no, ac_cv_strerror_r=no)) AC_MSG_RESULT($ac_cv_strerror_r) if test $ac_cv_strerror_r = yes; then AC_DEFINE([HAS_STRERROR_R],[1],[support of strerror_r]) Fi Created config.h will contain on LINUX on HP/UX it is defined as zero #ifndef HAS_STRERROR_R #define HAS_STRERROR_R 1 #endif Regards, Oliver
Oliver.Kowalke@qimonda.com wrote:
From : Beman Dawes
(defined(__linux) && (!defined(__USE_XOPEN2K) || defined(BOOST_SYSTEM_USE_STRERROR)))
Would autocnf be integrated into boost build process we could prevent such ugly Preprocessor defines.
No. I've read many of your replies about autoconf by now. And I'm unclear if you are purposefully not understanding other peoples explanations as to why it's not helpful. Both in the context of the original problem and many others.
AC_MSG_CHECKING([for strerror_r support]) [...]
We are aware of how autoconf works. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Would autocnf be integrated into boost build process we could prevent such ugly Preprocessor defines.
No. I've read many of your replies about autoconf by now. And I'm unclear if you are purposefully not understanding other peoples explanations as to why it's not helpful. Both in the context of the original problem and many others.
Sorry - maybe I'm too stupid I still don't know why autoconf is not helpful. A lot of projects use autoconf for portable programming (at least for UNIX). (defined(__linux) && (!defined(__USE_XOPEN2K) || ... I'm using autoconf in my projects (which compile and run on different UNIX flavours) and I don't have such statements like: defined(__linux) && (!defined(__USE_XOPEN2K) || ... Oliver
Oliver.Kowalke@qimonda.com wrote:
Would autocnf be integrated into boost build process we could prevent such ugly Preprocessor defines.
"Ugly" is subjective. I'm not sure why you find you find C preprocessor uglier that some other non-standard Unix-only preprocessor.
No. I've read many of your replies about autoconf by now. And I'm unclear if you are purposefully not understanding other peoples explanations as to why it's not helpful. Both in the context of the original problem and many others.
Sorry - maybe I'm too stupid I still don't know why autoconf is not helpful. A lot of projects use autoconf for portable programming (at least for UNIX).
"at least for Unix" is part of the problem. Windows users don't have m4, don't have shell, and don't have zillion of Unix tools that m4 macros might depend on. Speaking as Boost.Build maintainer, it would be great if Boost.Build support auto-configuration, including compile, link and run tests, for the cases where preprocessor is not adequate, but when this happen, that will be using Python or Boost.Jam language. - Volodya
From: Martin Bonner
From: Oliver.Kowalke@qimonda.com
With autoconfig the build process can check if strerror_r is avaliable and provide strerror as fall back.
Autoconfig can check if strerror_r is available ON THE BUILD MACHINE. It CANNOT tell whether it will be available on the target machines.
It is you fault if you distribute a software to an platform for which it wasn't build. If build and target machine have the same os version and release then the system calls should be the same.
Oliver.Kowalke@qimonda.com wrote:
From: Martin Bonner
From: Oliver.Kowalke@qimonda.com
With autoconfig the build process can check if strerror_r is avaliable and provide strerror as fall back.
Autoconfig can check if strerror_r is available ON THE BUILD MACHINE. It CANNOT tell whether it will be available on the target machines.
It is you fault if you distribute a software to an platform for which it wasn't build. If build and target machine have the same os version and release then the system calls should be the same.
And why do you think that build and target machine should have the same os version and release? It's quite reasonable to build things on operating system X version N and have it run on operating system Y version M. Compiler running on Linux and producing binaries for Windows is a common beast. It's quite possible to have compiler run on Solaris N and target Solaris N-1. However, that requires *specially configured* compiler. Among other things will be need access to the header files and libraries of the target OS. - Volodya
From: Vladimir Prus
From: Martin Bonner
From: Oliver.Kowalke@qimonda.com
With autoconfig the build process can check if strerror_r is avaliable and provide strerror as fall back.
Autoconfig can check if strerror_r is available ON THE BUILD MACHINE. It CANNOT tell whether it will be available on the target machines.
It is you fault if you distribute a software to an platform for which it wasn't build. If build and target machine have the same os version and release then the system calls should be the same.
And why do you think that build and target machine should have the same os version and release?
Because some system calls differ between the OS's and/or between releases. In this case the problem was that strerror_r is avaliable on LINUX and on Solaris 2.8 not. But Solaris 2.8 (and even HP/UX 11.11) provide an threadsafe strerror function. If I think on the BSD socket library - differences in the function flags and the behaviour Are common (even between releases).
It's quite reasonable to build things on operating system X version N and have it run on operating system Y version M. Compiler running on Linux and producing binaries for Windows is a common beast.
I think this is not true: UNIX : socket(). WIN: WSASocket()
Oliver.Kowalke@qimonda.com wrote:
It's quite reasonable to build things on operating system X version N and have it run on operating system Y version M. Compiler running on Linux and producing binaries for Windows is a common beast.
I think this is not true:
I've used such a cross-compiler personally. It works and the produced binaries run on Windows.
UNIX : socket(). WIN: WSASocket()
And? When you're building for mingw using Linux-hosted compiler, the set of header files and functions and preprocessor defines is the same as if you was running Windows-hosted compiler.
From: Martin Bonner
From: Oliver.Kowalke@qimonda.com
With autoconfig the build process can check if strerror_r is avaliable and provide strerror as fall back.
Autoconfig can check if strerror_r is available ON THE BUILD MACHINE. It CANNOT tell whether it will be available on the target machines.
It is you fault if you distribute a software to an platform for which it wasn't build. If build and target machine have the same os version and release then the system calls should be the same.
And why do you think that build and target machine should have the same os version and release?
Because some system calls differ between the OS's and/or between releases. In this case the problem was that strerror_r is avaliable on LINUX and on Solaris 2.8 not. But Solaris 2.8 (and even HP/UX 11.11) provide an threadsafe strerror function. If I think on the BSD socket library - differences in the function flags and the behaviour Are common (even between releases).
As I've mentioned above, if you have cross-compiler that run on Solaris N and targets Solaris N-1, that cross-compiler has the set of headers and libraries from Solaris N-1, so any properties of Solaris N-1 that are discoverable by preprocessor symbols, compile tests, or link tests, can be take into account. The only think you cannot do is build a program for Solaris N-1, run it, and draw any conclusions from that -- because you'll be running it on Solaris N. Do any of the differences you list above require running a program to check for them? - Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
It's quite reasonable to build things on operating system X version N and have it run on operating system Y version M. Compiler running on Linux and producing binaries for Windows is a common beast.
I think this is not true:
I've used such a cross-compiler personally. It works and the produced binaries run on Windows.
UNIX : socket(). WIN: WSASocket()
And? When you're building for mingw using Linux-hosted compiler, the set of header files and functions and preprocessor defines is the same as if you was running Windows-hosted compiler.
You have to insert your own preprocessor defines - which could be handled better with autoconf. It evaluates if the requested feature is available and produces the output. See my example with strerror/strerror_r in my previous mail. (without autoconf) #if defined (LINUX || Solaris_10) strerror_r #elif defined (Solaris_28 || HP/UX_11) strerror #else ... (autoconf - version) #ifdef HAS_STRERROR_R strerror_r #else strerror #endif
Oliver.Kowalke@qimonda.com wrote:
It's quite reasonable to build things on operating system X version N and have it run on operating system Y version M. Compiler running on Linux and producing binaries for Windows is a common beast.
I think this is not true:
I've used such a cross-compiler personally. It works and the produced binaries run on Windows.
UNIX : socket(). WIN: WSASocket()
And? When you're building for mingw using Linux-hosted compiler, the set of header files and functions and preprocessor defines is the same as if you was running Windows-hosted compiler.
You have to insert your own preprocessor defines - which could be handled better with autoconf. It evaluates if the requested feature is available and produces the output. See my example with strerror/strerror_r in my previous mail.
(without autoconf)
#if defined (LINUX || Solaris_10) strerror_r #elif defined (Solaris_28 || HP/UX_11) strerror #else ...
(autoconf - version)
#ifdef HAS_STRERROR_R strerror_r #else strerror #endif
The latter, of course, is somewhat better, but that's not what I'm saying. I'm saying that if you have write conditional logic for target = build case, and you have a cross-compiler, then things will just work. Autoconf might be a help for writing the conditionals, but it's completely independent from handling target != build case. - Volodya
Oliver.Kowalke@qimonda.com wrote:
No, that doesn't work; you need to know the OS version for deployment to know what's available at runtime.
Autoconfig could help in this place - could this be integrated in the boost build process?
Autoconfig will only help if you have Solaris N to Solaris M cross-compiler. Otherwise, autoconfig will happily check properties of the build system not target system. Until cross-compiler is used, discussion of using autoconf, or any other mechanisms, is moot. - Volodya
Autoconfig will only help if you have Solaris N to Solaris M cross-compiler. Otherwise, autoconfig will happily check properties of the build system not target system.
If I cross-compile an application for HP/UX 11.11 on Linux (for instance kernel 2.6.x) than this would result in a problem with ::accept(). If the listen socket on which ::accept() is called is non-blocking, then the returned socket from ::accept() is blocking. This behaviour is different on HP/UX 11.11 were the new socket is also non-blocking. Oliver
Oliver.Kowalke@qimonda.com wrote:
Autoconfig will only help if you have Solaris N to Solaris M cross-compiler. Otherwise, autoconfig will happily check properties of the build system not target system.
If I cross-compile an application for HP/UX 11.11 on Linux (for instance kernel 2.6.x) than this
What's "this" above?
would result in a problem with ::accept(). If the listen socket on which ::accept() is called is non-blocking, then the returned socket from ::accept() is blocking. This behaviour is different on HP/UX 11.11 were the new socket is also non-blocking.
I would have expected the cross-compiler to have some define that says you're compiling for HP/UX so that you change your code using preprocessor. If it's not possible, then you'd have to set your own define manually, when building for HP/UX. I don't think autoconf can run a binary for target system to check run-time properties, even if you have the target system around. Anyway, is your point that autoconf is also problematic, or what? - Volodya
would result in a problem with ::accept(). If the listen socket on which ::accept() is called is non-blocking, then the returned socket from ::accept() is blocking. This behaviour is different on HP/UX 11.11 were the new socket is also non-blocking.
I would have expected the cross-compiler to have some define that says you're compiling for HP/UX so that you change your code using preprocessor.
That's what autoconf does for you. The only thing you have to do is to prepare some macros which check if the requested feature is available and then produces a preprocessor define (like HAVE_MSG_NOSIGNAL). The benefit is that it is more genreric than checking in the code for the OS/OS version/OS release Like: #if defined (LINUX || Solaris_10) strerror_r #elif defined (Solaris_28 || HP/UX_11) strerror #else #ifdef HAS_STRERROR_R strerror_r #else strerror #endif
If it's not possible, then you'd have to set your own define manually, when building for HP/UX.
see above
I don't think autoconf can run a binary for target system to check run-time properties, even if you have the target system around.
Autoconf does run m4 macros (some already provided - but you can also implement your own) before you start compiling your source code.
Oliver.Kowalke@qimonda.com wrote:
would result in a problem with ::accept(). If the listen socket on which ::accept() is called is non-blocking, then the returned socket from ::accept() is blocking. This behaviour is different on HP/UX 11.11 were the new socket is also non-blocking.
I would have expected the cross-compiler to have some define that says you're compiling for HP/UX so that you change your code using preprocessor.
That's what autoconf does for you. The only thing you have to do is to prepare some macros which check if the requested feature is available and then produces a preprocessor define (like HAVE_MSG_NOSIGNAL). The benefit is that it is more genreric than checking in the code for the OS/OS version/OS release
It looks like this turns into general "autoconf is good" discussion, which is not how it started. Here's what you've said before: > No, that doesn't work; you need to know the OS version for > deployment to know what's available at runtime. Autoconfig could help in this place - could this be integrated in the boost build process? That statement seems to say that autoconf has additional support for the case where the target system is not the same as the build system, and such support can help with the filesystem library. Can you specifically say which support is that?
Like:
#if defined (LINUX || Solaris_10) strerror_r #elif defined (Solaris_28 || HP/UX_11) strerror #else
#ifdef HAS_STRERROR_R strerror_r #else strerror #endif
While autoconf's compile tests are more general than using just preprocessor symbols, it's not yet established that preprocessor symbols won't work in this case.
If it's not possible, then you'd have to set your own define manually, when building for HP/UX.
see above
I don't think autoconf can run a binary for target system to check run-time properties, even if you have the target system around.
Autoconf does run m4 macros (some already provided - but you can also implement your own) before you start compiling your source code.
I did not claim otherwise. But running m4 macros is not the same as running binaries -- you cannot run a binary for the target system unless you have the target system at hand. And even if you have it at hand, I don't think autoconf can run binaries for the target system. - Volodya
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
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
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
participants (8)
-
Beman Dawes -
Christopher Kohlhoff -
Glenn Schrader -
James Dennett -
Martin Bonner -
Oliver.Kowalke＠qimonda.com -
Rene Rivera -
Vladimir Prus