David Abrahams wrote:
on Fri Nov 02 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Well, that makes a lot of sense. But when I build/test with bjam the tail of bjam.log looks like:
gcc.archive ..\..\..\bin.v2\libs\serialization\build\gcc-3.4.4\debug\link-static \libboost_serialization-gcc34-d-1_34_1.a gcc.link ..\..\..\bin.v2\libs\serialization\test\test_shared_ptr_132_text_archiv e.test\gcc-3.4.4\debug\link-static\test_shared_ptr_132_text_archive.exe testing.capture-output ..\..\..\bin.v2\libs\serialization\test\test_shared_ptr_1 32_text_archive.test\gcc-3.4.4\debug\link-static\test_shared_ptr_132_text_archiv e.run ====== BEGIN OUTPUT ====== assertion "result.second" failed: file "..\..\..\libs\serialization\src\extended _type_info.cpp", line 75
EXIT STATUS: 34304 ====== END OUTPUT ====== **passed** ..\..\..\bin.v2\libs\serialization\test\test_shared_ptr_132_text_arch ive.test\gcc-3.4.4\debug\link-static\test_shared_ptr_132_text_archive.test ...updated 32 targets...
This looks like a serious bug, assuming you weren't doing a parallel build (in which case the **passed** message might belong to a different test).
I'm not using a parallel build.
Are you using the regular windows command shell to build with a cygwin GCC?
However, my default shell is the MKS Korn shell. Given that no one else has reported this that might be an issue. I don't know how bjam works but I would have thought that it invoked the compiler directly rather than through the current shell. I can try the the normal DOS-like shell or the cygwin shell if you think that would make a difference. Robert Ramey