Boost, VC++5 and PThreads-Win32 [newbee]
Hello, I have to use Boost with VC++5 even if it this compiler isn't supposed to be supported. That's because we have a quite huge software developped with VC++5 and we don't have enough time to re-pass the entire test book (several hundreds of pages with 10 pixel-sized fonts). By disabling the #error directive in the compiler configuration hpp file, I'm surprised to see all seem to work fine. So my 1st question is : - Why such a #error directive ? Moreover, I have a POSIX.1c compliant threads implementation under WIN32 (PThreads Win32 downloaded from the RedHat site) that I want to use. So my 2nd question is : - What are the right minimum set of #define's I have to put (_REENTRANT, _POSIX_THREADS, BOOST_DISABLE_WIN32, etc.) ? Thank you very, very, much in advance, Best regards, Regis.
Regis Desgroppes said:
Hello,
I have to use Boost with VC++5 even if it this compiler isn't supposed to be supported. That's because we have a quite huge software developped with VC++5 and we don't have enough time to re-pass the entire test book (several hundreds of pages with 10 pixel-sized fonts).
By disabling the #error directive in the compiler configuration hpp file, I'm surprised to see all seem to work fine. So my 1st question is : - Why such a #error directive ?
Someone else will have to address this.
Moreover, I have a POSIX.1c compliant threads implementation under WIN32 (PThreads Win32 downloaded from the RedHat site) that I want to use. So my 2nd question is : - What are the right minimum set of #define's I have to put (_REENTRANT, _POSIX_THREADS, BOOST_DISABLE_WIN32, etc.) ?
If you are using Jam, you only have to define the variable PTW32 to be "install-path library-name" (replacing install-path and library-name with the proper values for your needs). If you're not using Jam, check out the $BOOST_ROOT/libs/thread/build/threads.jam file to see how this is done in Jam (should be easy to read and translate to however your building). William E. Kempf
By disabling the #error directive in the compiler configuration hpp file, I'm surprised to see all seem to work fine. So my 1st question is : - Why such a #error directive ?
Someone else will have to address this.
Is the #error directive "Thread Support Unavailable"??? If so... Your getting lucky! You'll probably find runtime errors. The #error directive stops you compiling programs that include Boost.Threads with applications that use the single-threaded C runtime library. Change your application settings to link against the multi-threaded (debug) runtime library and the #error will go away and your program has a chance of working correctly. If you're not using the multi-threaded C runtime, you'll have problems with any calls that store data within the C runtime, e.g. gmtime, strtok (the list goes on). Even if you don't use these, you'll also have problems because your malloc implementation won't be thread-safe. If not then I'll let someone else address the issue (it will probably help if you tell us what the #error message is). - Dale.
The #error directive resides in <boost directory>/boost/config/compiler/visualc.hpp : // versions check: // we don't support Visual C++ prior to version 6: #if _MSC_VER < 1200 #error "Compiler not supported or configured - please reconfigure" #endif As you can see, the version check doesn't deal with threads at all... Moreover, I compile in (debug) multithreaded mode and the PThread/WIN32 library I have is itself compiled in (release) multithreaded mode so I'm not supposed to face problems with run-time errors due to using wrong C/C++ run-time libraries. What I've found in many boost sources is that there are a lot of #if _MSC_VER compared to values lesser than 1200 (VC++6), so at least a few parts of the sources are compatible with VC++5, right ? I'll be grateful if someone could give me a link that explain why the boost team has decided to put this version check (unconditional) while leaving parts of the sources with behaviors depending on previous versions of VC++... Thank you for your attention and your previous and next answers, Regis. Dale wrote:
By disabling the #error directive in the compiler configuration hpp file, I'm surprised to see all seem to work fine. So my 1st question is : - Why such a #error directive ?
Someone else will have to address this.
Is the #error directive "Thread Support Unavailable"???
If so...
Your getting lucky! You'll probably find runtime errors. The #error directive stops you compiling programs that include Boost.Threads with applications that use the single-threaded C runtime library.
Change your application settings to link against the multi-threaded (debug) runtime library and the #error will go away and your program has a chance of working correctly.
If you're not using the multi-threaded C runtime, you'll have problems with any calls that store data within the C runtime, e.g. gmtime, strtok (the list goes on). Even if you don't use these, you'll also have problems because your malloc implementation won't be thread-safe.
If not then I'll let someone else address the issue (it will probably help if you tell us what the #error message is).
- Dale.
Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
The #error directive resides in <boost directory>/boost/config/compiler/visualc.hpp :
// versions check: // we don't support Visual C++ prior to version 6: #if _MSC_VER < 1200 #error "Compiler not supported or configured - please reconfigure" #endif
Configuring boost to work (at least in some form) with the numerous compilers out there is very hard. Just look at the config section and you'll see the number of #define's involved. No testing is made for this compiler (which was released 5 1/2 years ago and replaced just over 4 years ago with VC6) and is severely broken. I guess no testing === not supported (we're professional here!)
As you can see, the version check doesn't deal with threads at all... Moreover, I compile in (debug) multithreaded mode and the PThread/WIN32 library I have is itself compiled in (release) multithreaded mode so I'm not supposed to face problems with run-time errors due to using wrong C/C++ run-time libraries.
Yep, that appears to be the case.
What I've found in many boost sources is that there are a lot of #if _MSC_VER compared to values lesser than 1200 (VC++6), so at least a few parts of the sources are compatible with VC++5, right ?
I'll be grateful if someone could give me a link that explain why the boost team has decided to put this version check (unconditional) while leaving parts of the sources with behaviors depending on previous versions of VC++...
The Boost 'team' consists of volunteers who contribute individual libraries. Some of these libraries were developed with support for VC5, most weren't. Boost is trying to remove checks for individual compilers in the source code and replace them with general checks that are configured with the config system. VC5 is so old and broken it's not registered on the current developers radar :-) I suggest that you fiddle with the config system (treating VC5 as VC6 initially) and run the regression tests to see how much/little of boost will work with VC5. - Dale.
Hello to Dale and to other attendees here, Even if VC++5 is definitely an old, broken C++ compiler, I use boost::shared_ptr's and boost::weak_ptr's while facing no problems when sharing them in separate threads (no double deallocation attempts, no memory leaks, no notable performance fall). Regards, Regis. Dale wrote:
The #error directive resides in <boost directory>/boost/config/compiler/visualc.hpp :
// versions check: // we don't support Visual C++ prior to version 6: #if _MSC_VER < 1200 #error "Compiler not supported or configured - please reconfigure" #endif
Configuring boost to work (at least in some form) with the numerous compilers out there is very hard. Just look at the config section and you'll see the number of #define's involved.
No testing is made for this compiler (which was released 5 1/2 years ago and replaced just over 4 years ago with VC6) and is severely broken.
I guess no testing === not supported (we're professional here!)
As you can see, the version check doesn't deal with threads at all... Moreover, I compile in (debug) multithreaded mode and the PThread/WIN32 library I have is itself compiled in (release) multithreaded mode so I'm not supposed to face problems with run-time errors due to using wrong C/C++ run-time libraries.
Yep, that appears to be the case.
What I've found in many boost sources is that there are a lot of #if _MSC_VER compared to values lesser than 1200 (VC++6), so at least a few parts of the sources are compatible with VC++5, right ?
I'll be grateful if someone could give me a link that explain why the boost team has decided to put this version check (unconditional) while leaving parts of the sources with behaviors depending on previous versions of VC++...
The Boost 'team' consists of volunteers who contribute individual libraries. Some of these libraries were developed with support for VC5, most weren't. Boost is trying to remove checks for individual compilers in the source code and replace them with general checks that are configured with the config system. VC5 is so old and broken it's not registered on the current developers radar :-)
I suggest that you fiddle with the config system (treating VC5 as VC6 initially) and run the regression tests to see how much/little of boost will work with VC5.
- Dale.
Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
participants (3)
-
Dale -
Regis Desgroppes -
William E. Kempf