[Boost.Config] Stlport patch for Sun compilers on Linux
Hi, I've attached a patch to fix this error with the sun compilers on Linux. http://tinyurl.com/6o4fxg I'm not well versed with the subtleties of Stlport (there may be better ways to code this). The patch merely avoids defining macro BOOST_NO_EXCEPTION_STD_NAMESPACE as the Stlport bundled with the Sun compilers on Linux seems to correctly put all type_info into the std namespace. The Sun compilers on Solaris still require this macro definition. I've tested that this fixes the type_info error with sun-5.9 on Linux and that it doesn't break the Sun tests on Solaris, okay to commit? -- Noel
K. Noel Belcourt:
Hi,
I've attached a patch to fix this error with the sun compilers on Linux.
I'm not well versed with the subtleties of Stlport (there may be better ways to code this). The patch merely avoids defining macro BOOST_NO_EXCEPTION_STD_NAMESPACE as the Stlport bundled with the Sun compilers on Linux seems to correctly put all type_info into the std namespace. The Sun compilers on Solaris still require this macro definition.
There is something wrong with these macros and their use. BOOST_NO_EXCEPTION_STD_NAMESPACE should ostensibly be defined when there is no std::exception. But there are places in Boost, throw_exception.hpp and detail/bad_weak_ptr.hpp for example, that use std::exception, without checking the macro. Many libraries include, directly or indirectly, one of these two headers. If the macro is correctly set for Sun CC on Solaris, they should fail to compile. But the absence of bug reports implies that they don't. The only compiler I know of that doesn't have type_info in std is Embedded VC++ 4.2; it is what prompted me to ask for the addition of BOOST_NO_STD_TYPEINFO to make shared_ptr compile. Even eVC++ 4.2 is able to eat std::exception though (if I recall).
On Sep 9, 2008, at 2:09 PM, Peter Dimov wrote:
K. Noel Belcourt:
Hi,
I've attached a patch to fix this error with the sun compilers on Linux.
I'm not well versed with the subtleties of Stlport (there may be better ways to code this). The patch merely avoids defining macro BOOST_NO_EXCEPTION_STD_NAMESPACE as the Stlport bundled with the Sun compilers on Linux seems to correctly put all type_info into the std namespace. The Sun compilers on Solaris still require this macro definition.
There is something wrong with these macros and their use. BOOST_NO_EXCEPTION_STD_NAMESPACE should ostensibly be defined when there is no std::exception. But there are places in Boost, throw_exception.hpp and detail/bad_weak_ptr.hpp for example, that use std::exception, without checking the macro. Many libraries include, directly or indirectly, one of these two headers. If the macro is correctly set for Sun CC on Solaris, they should fail to compile. But the absence of bug reports implies that they don't.
The only compiler I know of that doesn't have type_info in std is Embedded VC++ 4.2; it is what prompted me to ask for the addition of BOOST_NO_STD_TYPEINFO to make shared_ptr compile. Even eVC++ 4.2 is able to eat std::exception though (if I recall).
Okay, seems like we need to fix function_base.hpp to key off of BOOST_NO_STD_TYPEINFO rather than BOOST_NO_EXCEPTION_STD_NAMESPACE. With the attached patch to function_base.hpp, the both Sun and gcc compilers under Solaris and Linux are happy and there're no changes necessary to Boost.Config. Is this what you had in mind? -- Noel
Peter Dimov wrote:
The only compiler I know of that doesn't have type_info in std is Embedded VC++ 4.2; it is what prompted me to ask for the addition of BOOST_NO_STD_TYPEINFO to make shared_ptr compile. Even eVC++ 4.2 is able to eat std::exception though (if I recall).
There are a few other configurations where class "exception" may be present but in the global namespace: STLPort when import of C std lib names is disabled. VC6. VC6 + updated dinkumware std lib. John.
John Maddock:
Peter Dimov wrote:
The only compiler I know of that doesn't have type_info in std is Embedded VC++ 4.2; it is what prompted me to ask for the addition of BOOST_NO_STD_TYPEINFO to make shared_ptr compile. Even eVC++ 4.2 is able to eat std::exception though (if I recall).
There are a few other configurations where class "exception" may be present but in the global namespace:
STLPort when import of C std lib names is disabled. VC6. VC6 + updated dinkumware std lib.
VC6 definitely has std::exception. It's possible that STLPort on top of VC6 and with C import disabled doesn't, I can't check at the moment. Still, shared_ptr uses std::exception directly, it doesn't look at the macros, and nobody has reported it not to work. (It didn't work on eVC 4 for other reasons, but not for this one.)
Peter Dimov <pdimov <at> pdimov.com> writes:
K. Noel Belcourt:
I'm not well versed with the subtleties of Stlport (there may be better ways to code this). The patch merely avoids defining macro BOOST_NO_EXCEPTION_STD_NAMESPACE as the Stlport bundled with the Sun compilers on Linux seems to correctly put all type_info into the std namespace. The Sun compilers on Solaris still require this macro definition.
There is something wrong with these macros and their use. BOOST_NO_EXCEPTION_STD_NAMESPACE should ostensibly be defined when there is no std::exception. But there are places in Boost, throw_exception.hpp and detail/bad_weak_ptr.hpp for example, that use std::exception, without checking the macro. Many libraries include, directly or indirectly, one of these two headers. If the macro is correctly set for Sun CC on Solaris, they should fail to compile. But the absence of bug reports implies that they don't.
Okay, I've removed this macro definition from boost/config/stdlib/stlport.hpp as it's apparently no longer needed for stlport builds. Index: boost/config/stdlib/stlport.hpp =============================================== --- boost/config/stdlib/stlport.hpp (revision 49393) +++ boost/config/stdlib/stlport.hpp (working copy) @@ -127,7 +127,6 @@ || defined(_STLP_USE_OWN_NAMESPACE)) \ && (defined(__STL_VENDOR_GLOBAL_CSTD) \ || defined (_STLP_VENDOR_GLOBAL_CSTD)) # define BOOST_NO_STDC_NAMESPACE -# define BOOST_NO_EXCEPTION_STD_NAMESPACE # endif #elif defined(__BORLANDC__) && __BORLANDC__ < 0x560 // STLport doesn't import std::abs correctly: Per Peter's suggestion, I've modified throw_exception.hpp and detail/bad_weak_ptr.hpp to condition the use of std::exception on BOOST_NO_EXCEPTION_STD_NAMESPACE. Index: boost/detail/bad_weak_ptr.hpp =============================================== --- boost/detail/bad_weak_ptr.hpp (revision 49393) +++ boost/detail/bad_weak_ptr.hpp (working copy) @@ -23,6 +23,12 @@ # pragma warn -8026 // Functions with excep. spec. are not expanded inline #endif +#if defined(BOOST_NO_EXCEPTION_STD_NAMESPACE) +# define BOOST_STD_EXCEPTION ::exception +#else +# define BOOST_STD_EXCEPTION std::exception +#endif + namespace boost { @@ -36,7 +42,7 @@ # pragma option push -pc #endif -class bad_weak_ptr: public std::exception +class bad_weak_ptr: public BOOST_STD_EXCEPTION { public: Index: boost/throw_exception.hpp ================================================ --- boost/throw_exception.hpp (revision 49393) +++ boost/throw_exception.hpp (working copy) @@ -43,16 +43,22 @@ # define BOOST_THROW_EXCEPTION(x) ::boost::throw_exception(x) #endif +#if defined( BOOST_NO_EXCEPTION_STD_NAMESPACE ) +# define BOOST_STD_EXCEPTION ::exception +#else +# define BOOST_STD_EXCEPTION std::exception +#endif + namespace boost { #ifdef BOOST_NO_EXCEPTIONS -void throw_exception( std::exception const & e ); // user defined +void throw_exception( BOOST_STD_EXCEPTION const & e ); // user defined #else -inline void throw_exception_assert_compatibility( std::exception const & ) { } +void throw_exception_assert_compatibility( BOOST_STD_EXCEPTION const & ) { } template<class E> inline void throw_exception( E const & e ) {
The only compiler I know of that doesn't have type_info in std is Embedded VC++ 4.2; it is what prompted me to ask for the addition of BOOST_NO_STD_TYPEINFO to make shared_ptr compile. Even eVC++ 4.2 is able to eat std::exception though (if I recall).
I've patched function_base.hpp to use the typeinfo, rather than the exception, macro. Index: boost/function/function_base.hpp ================================================ --- boost/function/function_base.hpp (revision 49393) +++ boost/function/function_base.hpp (working copy) @@ -42,7 +42,7 @@ #endif // Define BOOST_FUNCTION_STD_NS to the namespace that contains type_info. -#ifdef BOOST_NO_EXCEPTION_STD_NAMESPACE +#ifdef BOOST_NO_STD_TYPEINFO // Embedded VC++ does not have type_info in namespace std # define BOOST_FUNCTION_STD_NS #else Any objection if I commit these to trunk? -- Noel
Hi, Both Sun and Pgi on Linux correctly put typeinfo into the std namespace, but function_base keys off the BOOST_NO_EXCEPTION_STD_NAMESPACE macro instead of the BOOST_NO_STD_TYPEINFO macro. The attached patch changes function_base to use the typeinfo macro. Because eVC 4.2 doesn't put typeinfo into the std namespace, I need to define BOOST_NO_STD_TYPEINFO only for this eVC version. Are these okay to commit? -- Noel
K. Noel Belcourt wrote:
Hi,
Both Sun and Pgi on Linux correctly put typeinfo into the std namespace, but function_base keys off the BOOST_NO_EXCEPTION_STD_NAMESPACE macro instead of the BOOST_NO_STD_TYPEINFO macro. The attached patch changes function_base to use the typeinfo macro. Because eVC 4.2 doesn't put typeinfo into the std namespace, I need to define BOOST_NO_STD_TYPEINFO only for this eVC version.
Are these okay to commit?
Is version 1202 specific to the embedded compiler, or should we check for defined(_WIN32_WCE) || defined(UNDER_CE) as well? John.
On Oct 20, 2008, at 2:28 AM, John Maddock wrote:
K. Noel Belcourt wrote:
Hi,
Both Sun and Pgi on Linux correctly put typeinfo into the std namespace, but function_base keys off the BOOST_NO_EXCEPTION_STD_NAMESPACE macro instead of the BOOST_NO_STD_TYPEINFO macro. The attached patch changes function_base to use the typeinfo macro. Because eVC 4.2 doesn't put typeinfo into the std namespace, I need to define BOOST_NO_STD_TYPEINFO only for this eVC version.
Are these okay to commit?
Is version 1202 specific to the embedded compiler, or should we check for defined(_WIN32_WCE) || defined(UNDER_CE) as well?
I'm not sure since I don't have access to this platform. Peter D. was kind enough to suggest I use version 1202 so I suspect it's specific to that version of eVC 4.2. -- Noel
K. Noel Belcourt wrote:
Is version 1202 specific to the embedded compiler, or should we check for defined(_WIN32_WCE) || defined(UNDER_CE) as well?
I'm not sure since I don't have access to this platform. Peter D. was kind enough to suggest I use version 1202 so I suspect it's specific to that version of eVC 4.2.
No I don't have access to that compiler either, in fact I *think* there *may* have been several embedded VC++ releases with versions 1200/1201/1202 but I'm not enturely sure... John.
John Maddock:
K. Noel Belcourt wrote:
Is version 1202 specific to the embedded compiler, or should we check for defined(_WIN32_WCE) || defined(UNDER_CE) as well?
I'm not sure since I don't have access to this platform. Peter D. was kind enough to suggest I use version 1202 so I suspect it's specific to that version of eVC 4.2.
No I don't have access to that compiler either, in fact I *think* there *may* have been several embedded VC++ releases with versions 1200/1201/1202 but I'm not enturely sure...
I think that: - 1200 is VC 6.0 and eVC 4.0; - 1201 is eVC 4.1; - 1202 is eVC 4.2. Since nobody uses eVC 4.0 and 4.1, I think that it'd be enough to test for 1202.
participants (4)
-
John Maddock -
K. Noel Belcourt -
Noel Belcourt
-
Peter Dimov