[thread] 1.36 thread.hpp compilation problem
I'm in the process of evaluating Boost 1.36 as a potential upgrade from 1.35, in part to get the critical fixes to Boost.Thread. I've found, however, that something appears to have been broken with the library-level header and the way that it includes all the more-specific headers. My cursory search of the mailing list didn't reveal any previous reports; my apologies if I missed something. Here's my one-line test program: #include <boost/thread.hpp> This compiles cleanly using 1.35, but with 1.36 there are a number of errors related to condition_variable::wait and shared_mutex: In file included from /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/shared_mutex.hpp:16, from /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread.hpp:22, from 136.C:1: /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'void boost::shared_mutex::lock_shared()': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:64: error: no matching function for call to 'boost::condition_variable::wait(<unresolved overloaded function type>)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'bool boost::shared_mutex::timed_lock_shared(const boost::system_time&)': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:91: error: no matching function for call to 'boost::condition_variable::timed_wait(<unresolved overloaded function type>, const boost::posix_time::ptime&)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:23: note: candidates are: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::system_time&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable_fwd.hpp:50: note: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::xtime&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'void boost::shared_mutex::lock()': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:135: error: no matching function for call to 'boost::condition_variable::wait(<unresolved overloaded function type>)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'bool boost::shared_mutex::timed_lock(const boost::system_time&)': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:148: error: no matching function for call to 'boost::condition_variable::timed_wait(<unresolved overloaded function type>, const boost::posix_time::ptime&)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:23: note: candidates are: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::system_time&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable_fwd.hpp:50: note: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::xtime&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'void boost::shared_mutex::lock_upgrade()': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:199: error: no matching function for call to 'boost::condition_variable::wait(<unresolved overloaded function type>)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'bool boost::shared_mutex::timed_lock_upgrade(const boost::system_time&)': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:211: error: no matching function for call to 'boost::condition_variable::timed_wait(<unresolved overloaded function type>, const boost::posix_time::ptime&)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:23: note: candidates are: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::system_time&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable_fwd.hpp:50: note: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::xtime&) /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp: In member function 'void boost::shared_mutex::unlock_upgrade_and_lock()': /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/shared_mutex.hpp:266: error: no matching function for call to 'boost::condition_variable::wait(<unresolved overloaded function type>)' /mathworks/devel/sandbox/cnewbold/3rdp/3p/install/unknown/glnxa64/boost/include/boost-1_36/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) -Chris
Hi, in my developement I use to include some tests that check that a header file compiles. Other boost developers do the same. How this is done now? We write a .cpp file including the header file // check_header1_compiles.cpp #include <boost/header1.hpp> and add it to the list of compile test test-suite LIB_inclusion : [ compile check_header1_compiles.cpp : : ] [ compile check_header2_compiles.cpp : : ] ... [ compile check_headerN_compiles.cpp : : ] Even if this is simple, the creation of the file is tedious. Do you know a simple way to do it? Has boost a policy about header files compilation? If not I think that we need it, and that this must be as easier to do as possible, for example by declaring the list of header files that need to pass this check. test-suite LIB_inclusion : [ check_header_compiles : header1.hpp header2.hpp ... headern.hpp : ] I have not tried to define the rule check_header_compiles using bjam, but I suppose that this is possible. Has some one already do something similar? What do you think? Vicente ----- Original Message ----- From: "Chris Newbold" <Chris.Newbold@mathworks.com> To: <boost@lists.boost.org> Sent: Tuesday, September 02, 2008 10:53 PM Subject: [boost] [thread] 1.36 thread.hpp compilation problem
I'm in the process of evaluating Boost 1.36 as a potential upgrade from 1.35, in part to get the critical fixes to Boost.Thread.
I've found, however, that something appears to have been broken with the library-level header and the way that it includes all the more-specific headers. My cursory search of the mailing list didn't reveal any previous reports; my apologies if I missed something.
Here's my one-line test program:
#include <boost/thread.hpp>
This compiles cleanly using 1.35, but with 1.36 there are a number of errors related to condition_variable::wait and shared_mutex:
<snip> -Chris
Hi Vicente ! An'n Freitag 05 September 2008 hett vicente.botet schreven:
Has some one already do something similar?
Steven Watanabe. See his mail: http://lists.boost.org/Archives/boost/2007/08/126417.php The sample code is attached there.
What do you think?
I've used it do check some of our internal headers. Works great. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
----- Original Message ----- From: "Jürgen Hunold" <juergen.hunold@ivembh.de> To: <boost@lists.boost.org> Sent: Friday, September 05, 2008 9:09 AM Subject: Re: [boost] Automating the header compilation check. was : [thread]1.36 thread.hpp compilation problem Hi Vicente ! An'n Freitag 05 September 2008 hett vicente.botet schreven:
Has some one already do something similar?
Steven Watanabe. See his mail: http://lists.boost.org/Archives/boost/2007/08/126417.php The sample code is attached there.
What do you think?
I've used it do check some of our internal headers. Works great. ____________ Jürgen Thanks for the pointer Vicente
vicente.botet wrote:
in my developement I use to include some tests that check that a header file compiles. Other boost developers do the same. How this is done now?
We write a .cpp file including the header file
// check_header1_compiles.cpp #include <boost/header1.hpp>
and add it to the list of compile test
test-suite LIB_inclusion : [ compile check_header1_compiles.cpp : : ] [ compile check_header2_compiles.cpp : : ] ... [ compile check_headerN_compiles.cpp : : ]
Even if this is simple, the creation of the file is tedious. Do you know a simple way to do it?
No, I've done this by hand in the past, and it's *very* tedious. BTW, it's not sufficient to simply include the header: if the header contains templates, then you also need to instantiate those templates to ensure everything they use is visible to them. Not sure how one would automate that :-( John.
AMDG John Maddock wrote:
No, I've done this by hand in the past, and it's *very* tedious.
BTW, it's not sufficient to simply include the header: if the header contains templates, then you also need to instantiate those templates to ensure everything they use is visible to them. Not sure how one would automate that :-(
I think it is sufficient for most purposes if you test with a compiler that checks non-dependent names when a template is defined. In Christ, Steven Watanabe
On Fri, Sep 5, 2008 at 2:10 AM, John Maddock <john@johnmaddock.co.uk> wrote:
vicente.botet wrote: BTW, it's not sufficient to simply include the header: if the header contains templates, then you also need to instantiate those templates to ensure everything they use is visible to them. Not sure how one would automate that :-(
I do think that we should have a system that automatically verifies that all public header files compile by themselves, but any #includes beyond what's needed to compile the header itself are not desirable. I specifically don't want any #includes that are not needed until a template is instantiated. If we have an automatic header test, I'd like it to attempt to remove #includes until it finds the minimum needed to compile the file, because I'm sure we have many #includes that perhaps were needed before but are no longer necessary. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
----- Original Message ----- From: "Emil Dotchevski" <emil@revergestudios.com> To: <boost@lists.boost.org> Sent: Friday, September 05, 2008 7:22 PM Subject: Re: [boost] Automating the header compilation check. was :[thread]1.36 thread.hpp compilation problem
On Fri, Sep 5, 2008 at 2:10 AM, John Maddock <john@johnmaddock.co.uk> wrote:
vicente.botet wrote: BTW, it's not sufficient to simply include the header: if the header contains templates, then you also need to instantiate those templates to ensure everything they use is visible to them. Not sure how one would automate that :-(
I do think that we should have a system that automatically verifies that all public header files compile by themselves, but any #includes beyond what's needed to compile the header itself are not desirable. I specifically don't want any #includes that are not needed until a template is instantiated.
If we have an automatic header test, I'd like it to attempt to remove #includes until it finds the minimum needed to compile the file, because I'm sure we have many #includes that perhaps were needed before but are no longer necessary.
I want to quote what Larry Evans said on another post "FWIW, I think this is a good test for every library header. I confess I've often wondered whether many of my headers include 1) too much or 2) not enough. This test would at least assure the 2) doesn't happen. " What you are asking corresponds to 1). It will be glad to have such a automatic system, but it will need surely much more effort to get working, and also a lot of compile time. Note that 2) has already been implemented by Steave W. Best, Vicente
on Fri Sep 05 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
On Fri, Sep 5, 2008 at 2:10 AM, John Maddock <john@johnmaddock.co.uk> wrote:
vicente.botet wrote: BTW, it's not sufficient to simply include the header: if the header contains templates, then you also need to instantiate those templates to ensure everything they use is visible to them. Not sure how one would automate that :-(
I do think that we should have a system that automatically verifies that all public header files compile by themselves, but any #includes beyond what's needed to compile the header itself are not desirable. I specifically don't want any #includes that are not needed until a template is instantiated.
If we have an automatic header test, I'd like it to attempt to remove #includes until it finds the minimum needed to compile the file, because I'm sure we have many #includes that perhaps were needed before but are no longer necessary.
I disagree. I may be able to use std::sort after #including only <vector>, because something in <vector> needs something in <algorithm>. My code should still #include <algorithm>, though. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
----- Original Message ----- From: "John Maddock" <john@johnmaddock.co.uk> To: <boost@lists.boost.org> Sent: Friday, September 05, 2008 11:10 AM Subject: Re: [boost] Automating the header compilation check. was :[thread]1.36 thread.hpp compilation problem
vicente.botet wrote:
in my developement I use to include some tests that check that a header file compiles. Other boost developers do the same. How this is done now?
We write a .cpp file including the header file
// check_header1_compiles.cpp #include <boost/header1.hpp>
and add it to the list of compile test
test-suite LIB_inclusion : [ compile check_header1_compiles.cpp : : ] [ compile check_header2_compiles.cpp : : ] ... [ compile check_headerN_compiles.cpp : : ]
Even if this is simple, the creation of the file is tedious. Do you know a simple way to do it?
No, I've done this by hand in the past, and it's *very* tedious.
BTW, it's not sufficient to simply include the header: if the header contains templates, then you also need to instantiate those templates to ensure everything they use is visible to them. Not sure how one would automate that :-(
Right, it is not enough, but it is already useful. When the developper wants to check the template instantiation with archetypes he/she will do it explicitly, so there is no problem. Vicente
AMDG vicente.botet wrote:
in my developement I use to include some tests that check that a header file compiles. Other boost developers do the same. How this is done now?
<snip>
Even if this is simple, the creation of the file is tedious. Do you know a simple way to do it?
I've automated it for the Units library Take a look at the Jamfile in libs/units/test_headers In Christ, Steven Watanabe
----- Original Message ----- From: "Steven Watanabe" <watanabesj@gmail.com> To: "Boost.Build developer's and user's list" <boost-build@lists.boost.org> Cc: <boost@lists.boost.org> Sent: Friday, September 05, 2008 4:48 PM Subject: Re: [Boost-build] Automating the header compilation check. was : [boost] [thread] 1.36 thread.hpp compilation problem
AMDG
vicente.botet wrote:
in my developement I use to include some tests that check that a header file compiles. Other boost developers do the same. How this is done now?
<snip>
Even if this is simple, the creation of the file is tedious. Do you know a simple way to do it?
I've automated it for the Units library Take a look at the Jamfile in libs/units/test_headers
Hi, It would be interesting to add this to the complete build, or to the inspection script. The rule takes all the files following the pattern *.hpp in the boost directory. Are there other files to check? Do we need to check for all these files? I don't know if all the files must follow this rule, in principle only the public files need to follow it. I don't see any way to kwnow that other than explicitly by the library owner. So maybe we need a rule that applies to some specific files test-suite units_headers : [ check_header : boost/header1.hpp ] [ check_header : boost/header2.hpp ] ... [ check_header : boost/headerN.hpp ] ; If a library owner want to check for all the *.hpp files in its own subdirectory she can write test-suite units_headers : [ check_headers : ../../.. : boost/units : *.hpp ] The check_header/s rule can be added to the testing module, as it is already the case of compile, run, ... Do you think that this should be added to boost? Best, Vicente
participants (7)
-
Chris Newbold -
David Abrahams -
Emil Dotchevski -
John Maddock -
Jürgen Hunold -
Steven Watanabe -
vicente.botet