[detail/lightweight_mutex] ODR violation
boost/detail/flyweight_mutex.hpp implements a mutex class based on a Win32 CRITICAL_SECTION or using Pthreads according to the following pp logic: #if defined(WIN32) || defined(_WIN32) || defined(__WIN32__) // based on CRITICAL_SECTION #elif defined(BOOST_HAS_PTHREADS) // based on Pthreads The problem with this is that WIN32 and related macros are not predefined in some environments (Cygwin at least) but rather they are defined inside windows.h, thus making the logic above dependent on the inclusion context. For instance, the two programs #include <boost/detail/lightweight_mutex.hpp> #include <iostream> int main() { std::cout<<sizeof(boost::detail::lightweight_mutex)<<std::endl; } and #include <windows.h> #include <boost/detail/lightweight_mutex.hpp> #include <iostream> int main() { std::cout<<sizeof(boost::detail::lightweight_mutex)<<std::endl; } output 4 and 24, respectively, under Cygwin. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz:
boost/detail/flyweight_mutex.hpp implements a mutex class based on a Win32 CRITICAL_SECTION or using Pthreads according to the following pp logic:
#if defined(WIN32) || defined(_WIN32) || defined(__WIN32__) // based on CRITICAL_SECTION #elif defined(BOOST_HAS_PTHREADS) // based on Pthreads
The problem with this is that WIN32 and related macros are not predefined in some environments (Cygwin at least) but rather they are defined inside windows.h, thus making the logic above dependent on the inclusion context.
Would it help if we reverse the two tests?
Peter Dimov ha escrito:
Joaquín Mª López Muñoz:
boost/detail/flyweight_mutex.hpp implements a mutex class based on a Win32 CRITICAL_SECTION or using Pthreads according to the following pp logic:
#if defined(WIN32) || defined(_WIN32) || defined(__WIN32__) // based on CRITICAL_SECTION #elif defined(BOOST_HAS_PTHREADS) // based on Pthreads
The problem with this is that WIN32 and related macros are not predefined in some environments (Cygwin at least) but rather they are defined inside windows.h, thus making the logic above dependent on the inclusion context.
Would it help if we reverse the two tests?
AFAICS, yes. The complementary problem (selecting Pthreads in Win32 when <pthread.h> has been included) seems not to happen when the logic is reversed, at least with pthreads-win32, but further confirmation on this issue would be great. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz ha escrito:
Peter Dimov ha escrito:
Joaquín Mª López Muñoz:
boost/detail/flyweight_mutex.hpp implements a mutex class based on a Win32 CRITICAL_SECTION or using Pthreads according to the following pp logic:
#if defined(WIN32) || defined(_WIN32) || defined(__WIN32__) // based on CRITICAL_SECTION #elif defined(BOOST_HAS_PTHREADS) // based on Pthreads
The problem with this is that WIN32 and related macros are not predefined in some environments (Cygwin at least) but rather they are defined inside windows.h, thus making the logic above dependent on the inclusion context.
Would it help if we reverse the two tests?
AFAICS, yes. The complementary problem (selecting Pthreads in Win32 when <pthread.h> has been included) seems not to happen when the logic is reversed, at least with pthreads-win32, but further confirmation on this issue would be great.
Another option could be to rely upon BOOST_HAS_PTHREADS and BOOST_HAS_WINTHREADS, as it looks like Boost.Config takes extreme care to guratnee that they're mutually exclusive. I guess John can shed some light on this. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
May I bring the post below to the attention of Boost.Config authors, as it discusses an issue of that library? Basically, is it guaranteed that the macros BOOST_HAS_PTHREADS and BOOST_HAS_WINTHREADS are mutually exclusive? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Joaquín Mª López Muñoz ha escrito:
Joaquín Mª López Muñoz ha escrito:
Peter Dimov ha escrito:
Joaquín Mª López Muñoz:
boost/detail/flyweight_mutex.hpp implements a mutex class based on a Win32 CRITICAL_SECTION or using Pthreads according to the following pp logic:
#if defined(WIN32) || defined(_WIN32) || defined(__WIN32__) // based on CRITICAL_SECTION #elif defined(BOOST_HAS_PTHREADS) // based on Pthreads
The problem with this is that WIN32 and related macros are not predefined in some environments (Cygwin at least) but rather they are defined inside windows.h, thus making the logic above dependent on the inclusion context.
Would it help if we reverse the two tests?
AFAICS, yes. The complementary problem (selecting Pthreads in Win32 when <pthread.h> has been included) seems not to happen when the logic is reversed, at least with pthreads-win32, but further confirmation on this issue would be great.
Another option could be to rely upon BOOST_HAS_PTHREADS and BOOST_HAS_WINTHREADS, as it looks like Boost.Config takes extreme care to guratnee that they're mutually exclusive. I guess John can shed some light on this.
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Joaquín Mª López Muñoz wrote:
May I bring the post below to the attention of Boost.Config authors, as it discusses an issue of that library? Basically, is it guaranteed that the macros BOOST_HAS_PTHREADS and BOOST_HAS_WINTHREADS are mutually exclusive?
Joaquin I'm sorry, I saw your message and then forgot about it! Yes, BOOST_HAS_PTHREADS and BOOST_HAS_WINTHREADS are mutually exclusive: on Cygwin BOOST_HAS_PTHREADS is the default, but you can override it by explicitly setting BOOST_HAS_WINTHREADS on the command line or in boost/config/user.hpp. HTH, John.
Hello Joaquín, Friday, September 7, 2007, 1:12:16 PM, you wrote:
boost/detail/flyweight_mutex.hpp implements a mutex class based on a Win32 CRITICAL_SECTION or using Pthreads according to the following pp logic:
The problem with this is that WIN32 and related macros are not predefined in some environments (Cygwin at least) but rather they are defined inside windows.h, thus making the logic above dependent on the inclusion context.
I guess, you're talking about MinGW cross-compiler, since Cygwin is a UNIX-like environment and doesn't have windows.h. So you shouldn't have included it in the first place. -- Best regards, Andrey mailto:andysem@mail.ru
----- Mensaje original ----- De: Andrey Semashev <andysem@mail.ru> Fecha: Viernes, Septiembre 7, 2007 5:44 pm Asunto: Re: [boost] [detail/lightweight_mutex] ODR violation Para: Joaquín Mª López Muñoz <boost@lists.boost.org>
Hello Joaquín,
Friday, September 7, 2007, 1:12:16 PM, you wrote:
boost/detail/flyweight_mutex.hpp implements a mutex class based on a Win32 CRITICAL_SECTION or using Pthreads according to the following pp logic:
The problem with this is that WIN32 and related macros are not predefined in some environments (Cygwin at least) but rather they are defined inside windows.h, thus making the logic above dependent on the inclusion context.
I guess, you're talking about MinGW cross-compiler, since Cygwin is a UNIX-like environment and doesn't have windows.h. So you shouldn't have included it in the first place.
Umm, no, I meant Cygwin: I can include <windows.h> and use its functionality (like CRITICAL_SECTIONs in this case, or some other Win32 functionality I please). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hello JOAQUIN, Saturday, September 8, 2007, 1:46:43 AM, you wrote:
I guess, you're talking about MinGW cross-compiler, since Cygwin is a UNIX-like environment and doesn't have windows.h. So you shouldn't have included it in the first place.
Umm, no, I meant Cygwin: I can include <windows.h> and use its functionality (like CRITICAL_SECTIONs in this case, or some other Win32 functionality I please).
I just tried and it, strange as it seems, works. Sorry for the noise then. -- Best regards, Andrey mailto:andysem@mail.ru
participants (5)
-
"JOAQUIN LOPEZ MU?Z" -
Andrey Semashev -
Joaquín Mª López Muñoz
-
John Maddock -
Peter Dimov