Boost.Threads metacomm regression tests not working
I've been mentioning this problem on the "Boost.Test problem" / "Boost.Threads problem" / "Boost.Threads status?" thread, but have been getting no help, so I thought I'd try a new thread. All of the Boost.Threads regression tests are failing due to an error like this: <quote> Cannot open include file: 'boost/thread/detail/config.hpp': No such file or directory </quote> The "missing" file is in cvs, and has been for a long time. Looking at the compiler command line, I see that the it contains -I"C:\Users\Administrator\boost\main\results\bin\boost\libs\thread\build" and no other directory; looking at the command line for other Boost libraries, I see that they also contain -I"C:\Users\Administrator\boost\main\boost". What do I need to do to get Boost.Threads to build with -I"C:\Users\Administrator\boost\main\boost"? Is it a problem with the Boost.Threads bjam file? A configuration problem with the regression tests? Something else? Mike
On Thu, 15 Jul 2004 08:40:06 -0400, Michael Glassford wrote
I've been mentioning this problem on the "Boost.Test problem" / "Boost.Threads problem" / "Boost.Threads status?" thread, but have been getting no help, so I thought I'd try a new thread.
All of the Boost.Threads regression tests are failing due to an error like this:
<quote> Cannot open include file: 'boost/thread/detail/config.hpp': No such file or directory </quote>
The "missing" file is in cvs, and has been for a long time. Looking at the compiler command line, I see that the it contains -I"C:\Users\Administrator\boost\main\results\bin\boost\libs\thread\build" and no other directory; looking at the command line for other Boost libraries, I see that they also contain -I"C:\Users\Administrator\boost\main\boost".
What do I need to do to get Boost.Threads to build with -I"C:\Users\Administrator\boost\main\boost"? Is it a problem with the Boost.Threads bjam file? A configuration problem with the regression tests? Something else?
Mike - This is also failing on my mini-Linux test with the same issue. http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake.html It's interesting that if I change to the libs/thread/build directory and type bjam the library builds, so it seems like maybe this is some new change in the bjam system causing this. That said in date_time there is <sysinclude>$(BOOST_ROOT) in the Jamfile to make sure the appropriate include path is available. I've locally modified the thread Jamfile to include a this sysinclude and I'm re-running the regression now. I'll let you know... Jeff
On Thu, 15 Jul 2004 07:55:44 -0700, Jeff Garland wrote
Mike -
This is also failing on my mini-Linux test with the same issue.
http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake.html
It's interesting that if I change to the libs/thread/build directory and type bjam the library builds, so it seems like maybe this is some new change in the bjam system causing this. That said in date_time there is
<sysinclude>$(BOOST_ROOT)
in the Jamfile to make sure the appropriate include path is available. I've locally modified the thread Jamfile to include a this sysinclude and I'm re-running the regression now. I'll let you know...
replies to self.... Adding the sysinclude indeed fixes the initial compilation problem. I've attached a patch of the change I made and I'll reupload the regression results -- there's more errors :-( Jeff
Jeff Garland wrote: > On Thu, 15 Jul 2004 07:55:44 -0700, Jeff Garland wrote > >>Mike - >> >>This is also failing on my mini-Linux test with the same issue. >> >>http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake.html >> >>It's interesting that if I change to the libs/thread/build directory >>and type bjam the library builds, so it seems like maybe this is >>some new change in the bjam system causing this. That said in >>date_time there is >> >> <sysinclude>$(BOOST_ROOT) >> >>in the Jamfile to make sure the appropriate include path is >>available. I've locally modified the thread Jamfile to include a >>this sysinclude and I'm re-running the regression now. I'll let you >>know... > > > replies to self.... > > Adding the sysinclude indeed fixes the initial compilation problem. Thanks for figuring this out! I'm far from a bjam expert, but one thing I don't quite understand is that the "<sysinclude>$(BOOST_ROOT)" is already defined in the thread_base template, which both of the templates you modified include. Is the problem perhaps that they include it only in the sources section and not in the requirements section? In other words, should your patch be modified to read as below? > I've > attached a patch of the change I made and I'll reupload the regression results > -- there's more errors :-( Hopefully I can deal with these once I can see them. > ------------------------------------------------------------------------ > > Index: Jamfile > =================================================================== > RCS file: /cvsroot/boost/boost/libs/thread/build/Jamfile,v > retrieving revision 1.28 > diff -u -r1.28 Jamfile > --- Jamfile 25 Jun 2004 20:17:19 -0000 1.28 > +++ Jamfile 15 Jul 2004 15:16:19 -0000 > @@ -49,6 +49,7 @@ > <template>thread_base > ../src/$(CPP_SOURCES).cpp > : ## requirements ## + <template>thread_base > <define>BOOST_THREAD_BUILD_LIB=1 > <runtime-link>static > # the common names rule ensures that the library will > @@ -63,6 +64,7 @@ > <template>thread_base > ../src/$(CPP_SOURCES).cpp > : ## requirements ## + <template>thread_base > <define>BOOST_THREAD_BUILD_DLL=1 > <runtime-link>dynamic > # the common names rule ensures that the library will Mike
Michael Glassford wrote:
Jeff Garland wrote:
On Thu, 15 Jul 2004 07:55:44 -0700, Jeff Garland wrote
Mike -
It's interesting that if I change to the libs/thread/build directory and type bjam the library builds, so it seems like maybe this is some new change in the bjam system causing this. That said in date_time there is <sysinclude>$(BOOST_ROOT) in the Jamfile to make sure the appropriate include path is available. I've locally modified the thread Jamfile to include a this sysinclude and I'm re-running the regression now. I'll let you know...
Adding the sysinclude indeed fixes the initial compilation problem.
I'm far from a bjam expert, but one thing I don't quite understand is that the "<sysinclude>$(BOOST_ROOT)" is already defined in the thread_base template, which both of the templates you modified include. Is the problem perhaps that they include it only in the sources section and not in the requirements section? In other words, should your patch be modified to read as below?
No. I would say this is a bug in the Boost.Build. Using the template should be added the needed <sysinclude>. I'll look at fixing this, assuming I can replicate it, but you should applies Jeff's changes just to get it working for the release testing. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Rene Rivera wrote:
Michael Glassford wrote:
Jeff Garland wrote:
On Thu, 15 Jul 2004 07:55:44 -0700, Jeff Garland wrote
Mike -
It's interesting that if I change to the libs/thread/build directory and type bjam the library builds, so it seems like maybe this is some new change in the bjam system causing this. That said in date_time there is <sysinclude>$(BOOST_ROOT) in the Jamfile to make sure the appropriate include path is available. I've locally modified the thread Jamfile to include a this sysinclude and I'm re-running the regression now. I'll let you know...
Adding the sysinclude indeed fixes the initial compilation problem.
I'm far from a bjam expert, but one thing I don't quite understand is that the "<sysinclude>$(BOOST_ROOT)" is already defined in the thread_base template, which both of the templates you modified include. Is the problem perhaps that they include it only in the sources section and not in the requirements section? In other words, should your patch be modified to read as below?
No. I would say this is a bug in the Boost.Build. Using the template should be added the needed <sysinclude>. I'll look at fixing this, assuming I can replicate it,
OK, that's good to know.
but you should applies Jeff's changes just to get it working for the release testing.
Thanks, I did. Mike
Jeff Garland wrote:
On Thu, 15 Jul 2004 07:55:44 -0700, Jeff Garland wrote
Mike -
This is also failing on my mini-Linux test with the same issue.
This is cleared up now, as you said.
http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake.html
It's interesting that if I change to the libs/thread/build directory and type bjam the library builds, so it seems like maybe this is some new change in the bjam system causing this. That said in date_time there is
<sysinclude>$(BOOST_ROOT)
in the Jamfile to make sure the appropriate include path is available. I've locally modified the thread Jamfile to include a this sysinclude and I'm re-running the regression now. I'll let you know...
replies to self....
Adding the sysinclude indeed fixes the initial compilation problem. I've attached a patch of the change I made and I'll reupload the regression results -- there's more errors :-(
I've fixed these errors (in read_write_mutex.cpp) as well, but the LinuxMandrake tests haven't re-run yet. Ditto for the Darwin tests, which are failing with these same errors. For the HP-UX tests: These are failing with the error "Error 119: "/home/tk/boost_regression/boost/boost/config/requires_threads.hpp", line 71 # #error "Compiler threading support is not turned on. Please set the correct command line options for threading: -mt"" Apparently the bjam configuration for this compiler is incorrect? For the win32_metacomm tests: Boost.Threads is now passing for msvc, msvc-stlport, vc7, and vc7.1, except for the test_read_write_mutex test, which is still failing on all toolsets with the error "Cannot open include file: 'boost/thread/detail/config.hpp'". Hopefully that test didn't re-run for some reason? The borland-5.6.4, cwpro8, intel-win32-7.1-vc6, intel- win32- 7.1- vc6- stlport- 4.5.3, and meta- como- win32- 4.3.3- vc7 toolsets are also still failing with the error "Cannot open include file: 'boost/thread/detail/config.hpp'". Hopefully those tests didn't re-run for some reason? Mike
Michael Glassford <glassfordm@hotmail.com> writes:
Jeff Garland wrote:
On Thu, 15 Jul 2004 07:55:44 -0700, Jeff Garland wrote
Mike -
This is also failing on my mini-Linux test with the same issue.
This is cleared up now, as you said.
http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake.html
It's interesting that if I change to the libs/thread/build directory and type bjam the library builds, so it seems like maybe this is some new change in the bjam system causing this. That said in date_time there is
<sysinclude>$(BOOST_ROOT)
in the Jamfile to make sure the appropriate include path is available. I've locally modified the thread Jamfile to include a this sysinclude and I'm re-running the regression now. I'll let you know... replies to self.... Adding the sysinclude indeed fixes the initial compilation problem. I've attached a patch of the change I made and I'll reupload the regression results -- there's more errors :-(
I've fixed these errors (in read_write_mutex.cpp) as well, but the LinuxMandrake tests haven't re-run yet. Ditto for the Darwin tests, which are failing with these same errors.
For the HP-UX tests:
These are failing with the error "Error 119: "/home/tk/boost_regression/boost/boost/config/requires_threads.hpp", line 71 # #error "Compiler threading support is not turned on. Please set the correct command line options for threading: -mt""
Apparently the bjam configuration for this compiler is incorrect?
It is correct. Actually the HP pthreads headers are incomplete, IIRC. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Fri, 16 Jul 2004 09:24:00 -0400, Michael Glassford wrote
I've fixed these errors (in read_write_mutex.cpp) as well, but the LinuxMandrake tests haven't re-run yet. Ditto for the Darwin tests, which are failing with these same errors.
New results are on sourceforge now. Looks like you didn't quite slay it. But at least down to one failure now :-) http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake-links.html#thr... Jeff
Jeff Garland wrote:
On Fri, 16 Jul 2004 09:24:00 -0400, Michael Glassford wrote
I've fixed these errors (in read_write_mutex.cpp) as well, but the LinuxMandrake tests haven't re-run yet. Ditto for the Darwin tests, which are failing with these same errors.
New results are on sourceforge now. Looks like you didn't quite slay it. But at least down to one failure now :-)
http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake-links.html#thr...
I've fixed some, perhaps all, of these too, now. Thanks, Mike
Michael Glassford writes:
Jeff Garland wrote:
On Fri, 16 Jul 2004 09:24:00 -0400, Michael Glassford wrote
I've fixed these errors (in read_write_mutex.cpp) as well, but the LinuxMandrake tests haven't re-run yet. Ditto for the Darwin tests, which are failing with these same errors.
New results are on sourceforge now. Looks like you didn't quite slay it. But at least down to one failure now :-)
http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake-links.html#thr...
I've fixed some, perhaps all, of these too, now.
Thank you, Win32 results look *much* better now! "test_read_write_mutex" is failing on all compilers, though -- http://tinyurl.com/4s58j, and "test_thread" shows a regression on VC7 -- http://tinyurl.com/5y8yh. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Michael Glassford writes:
Jeff Garland wrote:
On Fri, 16 Jul 2004 09:24:00 -0400, Michael Glassford wrote
I've fixed these errors (in read_write_mutex.cpp) as well, but the LinuxMandrake tests haven't re-run yet. Ditto for the Darwin tests, which are failing with these same errors.
New results are on sourceforge now. Looks like you didn't quite slay it. But at least down to one failure now :-)
http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake-links.html#thr...
I've fixed some, perhaps all, of these too, now.
Thank you, Win32 results look *much* better now! "test_read_write_mutex" is failing on all compilers, though -- http://tinyurl.com/4s58j, and "test_thread" shows a regression on VC7 -- http://tinyurl.com/5y8yh.
FWIW, "test_read_write_mutex" is failing on all Linux compilers, too. Some compilers emit errors, the other compilers create binaries that produce deadlocks when run. This should be fixed ASAP, since manual intervention is required to kill the dead-locked processes. Regards, m
Martin Wille wrote:
FWIW, "test_read_write_mutex" is failing on all Linux compilers, too.
Some compilers emit errors, the other compilers create binaries that produce deadlocks when run. This should be fixed ASAP, since manual intervention is required to kill the dead-locked processes.
FYI, I hope this situation is improving, though apparently it's not yet completely fixed. Mike
Aleksey Gurtovoy wrote:
Michael Glassford writes:
Jeff Garland wrote:
On Fri, 16 Jul 2004 09:24:00 -0400, Michael Glassford wrote
I've fixed these errors (in read_write_mutex.cpp) as well, but the LinuxMandrake tests haven't re-run yet. Ditto for the Darwin tests, which are failing with these same errors.
New results are on sourceforge now. Looks like you didn't quite slay it. But at least down to one failure now :-)
http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake-links.html#thr...
I've fixed some, perhaps all, of these too, now.
Thank you, Win32 results look *much* better now! "test_read_write_mutex" is failing on all compilers, though -- http://tinyurl.com/4s58j, and "test_thread" shows a regression on VC7 -- http://tinyurl.com/5y8yh.
Yes, I was aware of this and hope to work on it soon. The meta-como-win32-4.3.3-vc7 regression tests are giving the error: "C:\Users\Administrator\boost\main\boost\boost/config/requires_threads.hpp", line 29: catastrophic error #35: #error directive: "Threading support unavailable: it has been explicitly disabled with BOOST_DISABLE_THREADS" # error "Threading support unavailable: it has been explicitly disabled with BOOST_DISABLE_THREADS" This is because -dBOOST_DISABLE_WIN32 is being passed on the compiler's command line. Does anyone know why this is so? Thanks, Mike
participants (6)
-
Aleksey Gurtovoy -
David Abrahams -
Jeff Garland -
Martin Wille -
Michael Glassford -
Rene Rivera