On Friday 19 September 2014 15:56:26 Suckow, Thomas J wrote:
Would a bjam.log from a failing RHEL machine help?
There is everything from: ../libs/multiprecision/test/test_rat_float_interconv.cpp:195: error: '>>' should be '> >' within a nested template argument list
To: /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/s hared_ptr.h:146: error: cannot use typeid with -fno-rtti
It takes 12min for my build to fail, I could up the build once an hour if that might help. I could even auto upload the bjam.log to the regression ftp.
This sounds like the build actually starts (i.e. the testing tools are built successfully and library tests began running, some of them failing). This is not the problem we're seeing, but it would be interesting to know why it doesn't manifest in your case. Did you somehow modify your build scripts? Do you manually invoke 'b2 headers' before starting tests? Do you delete the boost directory before running tests? Is there anything special in your user-config.jam? How do you start tests? There's clearly some difference between testers, which makes some of them fail and others succeed.
I had brought up the issue with the headers target in the past on the boost-build list.
For it to work for me I use: <use>/boost//headers
<implicit-dependency>/boost//headers
This was a breaking change in 1.56 for our codebase as before we simply included the /boost//headers target. If this is the intended behavior of use and implicit-dependancy I think it is possible to make the headers target an alias that has a usage-requirement of the use and implicit-dependancy of the real headers target. This would make the headers target behave like it did before 1.56. There seemed to be little interest when I brought it up before, I think I was the only one affected at the time.
I'm not a Boost.Build expert so I didn't quite understand your way of fixing it. Could you specify how and what code you changed (i.e. a patch or modified code sample)?