[1.39.0] Beta candidate
The beta candidate files are up at http://boost.cowic.de/rc/ Before pushing these out to SourceForge, it would be great if a few Boosters could download and try them out as a final QA check. Post your experiences here. Thanks, --Beman
Hi there, On a vanilla OpenSUSE 11.1, 64 bit, g++ 4.3.2 installation: - ran the bootstrap script (o.k.) - Adjusted project-config.jam: removed the lines after option.set prefix, and set the prefix to /opt/boost139 - ran "./bjam -j 4" (this is a 4-core machine) . Note: There was a long list of warnings -- too many to list here. I'd be happy to send interested parties the compilation output - ran "bjam install" (o.k.) - Tried to compile my rather complex and heavily Boost-based library with it. o Had to modify my top-level CMakeLists.txt file with 'SET (Boost_ADDITIONAL_VERSIONS "1.39" "1.39.0")', as the cmake 2.6.3 FindBoost.cmake module does not know about Boost 1.39 yet. o Added the threadpool.sf.net threadpool library to Boost, as this is needed by my application o Compilation happened in DEBUG mode - many additional checks are then added to the code. o Used the "-Wall -Wno-unused -ansi -pthread" flags o Compilation of my application succeeded without warnings o Unit tests report no errors o *** every application based on my library that I tried does its job, but segfaults upon exit *** This is something I had observed last with Boost 1.36 and which at that time could be traced back to a problem in the serialization library. I haven't had time to search for the cause of the problem this time yet. The code runs fine with Boost 1.38 . I have verified (using "ldd") that the segfaulting applications are linked only to Boost 1.39 libraries. I am also sure that I'm using the correct Boost headers, as my headers specifically ask for the BOOST version to be >= 103900 (through a global define which I have adjusted accordingly). My application uses the date_time, system, thread, serialization, program_options and test_exec_monitor libraries, and of course a number of header-only libraries (shared_ptr, lexical_cast, cstdint, ...). Best Regards, Ruediger Beman Dawes wrote:
The beta candidate files are up at http://boost.cowic.de/rc/
Before pushing these out to SourceForge, it would be great if a few Boosters could download and try them out as a final QA check. Post your experiences here.
Thanks,
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ruediger Berlich wrote:
o *** every application based on my library that I tried does its job, but segfaults upon exit *** This is something I had observed last with Boost 1.36 and which at that time could be traced back to a problem in the serialization library. I haven't had time to search for the cause of the problem this time yet. The code runs fine with Boost 1.38 . I have verified (using "ldd") that the segfaulting applications are linked only to Boost 1.39 libraries. I am also sure that I'm using the correct Boost headers, as my headers specifically ask for the BOOST version to be >= 103900 (through a global define which I have adjusted accordingly).
I remember that one, it was nasty. Looks like some work has been done in there since 1.38: http://sodium.resophonic.com/git/boost/commit/?h=release&id=c7e977901094b902b12937dda9994593dbafdc43 I haven't taken a close look, but this looks a little suspicious: http://sodium.resophonic.com/git/boost/diff/libs/serialization/src/extended_type_info_typeid.cpp?h=release&id=c7e977901094b902b12937dda9994593dbafdc43 A backtrace would be helpful... -t
Hi Troy, gdb reports: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff60274b8 in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 More (albeit IMHO not very helpful) details from the backtrace can be found at the end of this post. Somehow looks like an infinite recursion ? Note that I can of course not rule out a problem in my own code. However, this "feels" like the pre-1.38 problem in that it does not affect the runtime behaviour of my programs (nor of the library's tests) and that the segfault happens after the last statement in main(). And as I said, the code runs fine with 1.38 . Best Regards, Ruediger troy d. straszheim wrote:
I remember that one, it was nasty. Looks like some work has been done in there since 1.38:
http://sodium.resophonic.com/git/boost/commit/?h=release&id=c7e977901094b902b12937dda9994593dbafdc43
I haven't taken a close look, but this looks a little suspicious:
A backtrace would be helpful...
/***************************************************************************/ #0 0x00007ffff60274b8 in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #1 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #2 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #3 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #4 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #5 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #6 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #7 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #8 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #9 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #10 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #11 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #12 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #13 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #14 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #15 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_sh ortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #16 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #17 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #18 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #19 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #20 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #21 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #22 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #23 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #24 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #25 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #26 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #27 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #28 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #29 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #30 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #31 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #32 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #33 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #34 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #35 0x00007ffff6027af7 in boost::serialization::void_cast_detail::void_caster_shortcut::~void_caster_shortcut() () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 #36 0x00007ffff60275fb in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0 [...] This goes on forever. I have stopped looking at #3265 of gdb's backtrace.
Ruediger Berlich wrote:
Hi Troy,
gdb reports:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff60274b8 in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0
More (albeit IMHO not very helpful) details from the backtrace can be found at the end of this post. Somehow looks like an infinite recursion ?
Note that I can of course not rule out a problem in my own code. However, this "feels" like the pre-1.38 problem in that it does not affect the runtime behaviour of my programs (nor of the library's tests) and that the segfault happens after the last statement in main(). And as I said, the code runs fine with 1.38 .
Hm. I can't reproduce it. I'm not getting the error with the release beta. One thing I stumbled on when looking at this last time was the following gcc flag: ---- -fuse-cxa-atexit Register destructors for objects with static storage duration with the __cxa_atexit function rather than the atexit function. This option is required for fully standards-compliant handling of static destructors, but will only work if your C library supports __cxa_atexit. ---- and as I recall, '-fno-use-cxa-atexit' was on by default on the linux distribution I was on (might have been ubuntu 8.04). I'm still curious as to when that flag could possibly be useful. -t
troy d. straszheim wrote:
Ruediger Berlich wrote:
Hi Troy,
gdb reports:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff60274b8 in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0
FYI - one of the most significant changes from 1.38 to 1.39 is a change to void_cast system. Pre 1.38 void_cast was not thread safe. 1.38 made void_cast (and the whole library) threadsaft. But the required void_cast implementation was very, very slow. The changes in 1.39 correct the speed problem while still keeping the library thread safe at the cost of making void_cast ever more subtle and intricate. It would be fairly easy to test this by running the serializaiton tests and verifying that only those tests which invoke void cast are the ones that fail.
More (albeit IMHO not very helpful) details from the backtrace can be found at the end of this post. Somehow looks like an infinite recursion ? Note that I can of course not rule out a problem in my own code. However, this "feels" like the pre-1.38 problem in that it does not affect the runtime behaviour of my programs (nor of the library's tests) and that the segfault happens after the last statement in main(). And as I said, the code runs fine with 1.38 .
Hm. I can't reproduce it. I'm not getting the error with the release beta.
One thing I stumbled on when looking at this last time was the following gcc flag:
----
-fuse-cxa-atexit
Register destructors for objects with static storage duration with the __cxa_atexit function rather than the atexit function. This option is required for fully standards-compliant handling of static destructors, but will only work if your C library supports __cxa_atexit.
You could be on to something here. One thing that I discovered is that on some platforms, the order of static destructors is not necessarily the reverse order of the corresponding static constructors. To address this, we've added some extra if statements which in theory should never be necessary but seems in fact that they might be. If you could indicate the line of source code, we might be able to apply this fix. Robert Ramey
----
and as I recall, '-fno-use-cxa-atexit' was on by default on the linux distribution I was on (might have been ubuntu 8.04). I'm still curious as to when that flag could possibly be useful.
-t
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Beman Dawes wrote:
The beta candidate files are up at http://boost.cowic.de/rc/
Before pushing these out to SourceForge, it would be great if a few Boosters could download and try them out as a final QA check. Post your experiences here.
I still have the same problem as before on cygwin. I run ./bootstrap.sh and then ./bjam --help and get this: Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17 ... and then bjam just hangs with the cpu pegged at 100%. I tried ash.exe and rebaseall like someone suggested, but it hasn't helped. Can anybody else reproduce this? FWIW, a plain "./bjam" doesn't hang and seems to kick off a proper build. Very odd. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Beman Dawes wrote:
The beta candidate files are up at http://boost.cowic.de/rc/
Before pushing these out to SourceForge, it would be great if a few Boosters could download and try them out as a final QA check. Post your experiences here.
I still have the same problem as before on cygwin. I run ./bootstrap.sh and then ./bjam --help and get this:
Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17
... and then bjam just hangs with the cpu pegged at 100%. I tried ash.exe and rebaseall like someone suggested, but it hasn't helped. Can anybody else reproduce this?
For how long is this happening? Can you attach to bjam with a debugger, and get a stacktrace? - Volodya
Vladimir Prus wrote:
Eric Niebler wrote:
I still have the same problem as before on cygwin. I run ./bootstrap.sh and then ./bjam --help and get this:
Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17
... and then bjam just hangs with the cpu pegged at 100%. I tried ash.exe and rebaseall like someone suggested, but it hasn't helped. Can anybody else reproduce this?
For how long is this happening? Can you attach to bjam with a debugger, and get a stacktrace?
I've never had any gdb-foo to speak of, and certainly not on cygwin. If I break in to bjam.exe from gdb (Ctrl-C, right?), I see this: (gdb) info threads * 6 thread 635300.0x9b304 0x762f6e39 in PulseEvent () from /cygdrive/c/Windows/system32/kernel32.dll 5 thread 635300.0x9b1e4 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll 4 thread 635300.0x9b1dc 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll 3 thread 635300.0x9b1c4 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll 1 thread 635300.0x9b1a8 0x00404a3b in ?? () (gdb) tb No default breakpoint address now. (gdb) bt #0 0x762f6e39 in PulseEvent () from /cygdrive/c/Windows/system32/kernel32.dll #1 0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll #2 0x00000000 in ?? () (gdb) thread 1 [Switching to thread 1 (thread 635300.0x9b1a8)]#0 0x00404a3b in ?? () (gdb) bt #0 0x00404a3b in ?? () #1 0x00000000 in ?? () (gdb) Not much there, is there? Is there anything specific you'd like me to try? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Vladimir Prus wrote:
Eric Niebler wrote:
I still have the same problem as before on cygwin. I run ./bootstrap.sh and then ./bjam --help and get this:
Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17
... and then bjam just hangs with the cpu pegged at 100%. I tried ash.exe and rebaseall like someone suggested, but it hasn't helped. Can anybody else reproduce this?
For how long is this happening? Can you attach to bjam with a debugger, and get a stacktrace?
I've never had any gdb-foo to speak of, and certainly not on cygwin. If I break in to bjam.exe from gdb (Ctrl-C, right?), I see this:
(gdb) info threads * 6 thread 635300.0x9b304 0x762f6e39 in PulseEvent () from /cygdrive/c/Windows/system32/kernel32.dll 5 thread 635300.0x9b1e4 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll 4 thread 635300.0x9b1dc 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll 3 thread 635300.0x9b1c4 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll 1 thread 635300.0x9b1a8 0x00404a3b in ?? () (gdb) tb No default breakpoint address now. (gdb) bt #0 0x762f6e39 in PulseEvent () from /cygdrive/c/Windows/system32/kernel32.dll #1 0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll #2 0x00000000 in ?? () (gdb) thread 1 [Switching to thread 1 (thread 635300.0x9b1a8)]#0 0x00404a3b in ?? () (gdb) bt #0 0x00404a3b in ?? () #1 0x00000000 in ?? () (gdb)
Not much there, is there? Is there anything specific you'd like me to try?
Try: thread apply all backtrace to get backtrace in all threads. I'm not overly optimistic :-( - Volodya
Vladimir Prus wrote:
Try:
thread apply all backtrace
to get backtrace in all threads. I'm not overly optimistic :-(
Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17 (no debugging symbols found) [New thread 636680.0x9b020] [New thread 636680.0x9b694] [New thread 636680.0x9b670] Program received signal SIGINT, Interrupt. [Switching to thread 636680.0x9b670] 0x762f6e39 in PulseEvent (Quit (gdb) thread apply all backtrace Thread 6 (thread 636680.0x9b670): #0 0x762f6e39 in PulseEvent () from /cygdrive/c/Windows/system32/kernel32.dll #1 0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll #2 0x00000000 in ?? () Thread 5 (thread 636680.0x9b694): #0 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x76fa9254 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x762dc244 in WaitForSingleObjectEx () from /cygdrive/c/Windows/system32/kernel32.dll #3 0x000001e0 in ?? () #4 0x00000000 in ?? () Thread 4 (thread 636680.0x9b020): #0 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x76fa9254 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x762dc244 in WaitForSingleObjectEx () from /cygdrive/c/Windows/system32/kernel32.dll #3 0x000001fc in ?? () #4 0x00000000 in ?? () Thread 3 (thread 636680.0x9b7d4): #0 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x76fa8c74 in ntdll!ZwReadFile () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x762d046b in ReadFile () from /cygdrive/c/Windows/system32/kernel32.dll #3 0x00000110 in ?? () #4 0x00000000 in ?? () Thread 1 (thread 636680.0x9b5c0): #0 0x00411232 in ?? () #1 0x00fb22c0 in ?? () #2 0x00229354 in ?? () #3 0x00229368 in ?? () #4 0x00407538 in ?? () #5 0x01971f27 in ?? () #6 0x010e16bc in ?? () #7 0x002295cc in ?? () #8 0x01088553 in ?? () #9 0x01088553 in ?? () #10 0x01088551 in ?? () #11 0x00229a08 in ?? () #12 0x00403771 in ?? () #13 0x002295c0 in ?? () #14 0x01088551 in ?? () #15 0x01088551 in ?? () #16 0x00229de8 in ?? () #17 0x00000000 in ?? () #0 0x762f6e39 in PulseEvent () from /cygdrive/c/Windows/system32/kernel32.dll Looks like bjam.exe is missing debug symbols. Is there a way to build a debug bjam.exe, perhaps using jam/src/build.sh? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Vladimir Prus wrote:
Try:
thread apply all backtrace
to get backtrace in all threads. I'm not overly optimistic :-(
Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17
(no debugging symbols found) [New thread 636680.0x9b020] [New thread 636680.0x9b694] [New thread 636680.0x9b670]
Program received signal SIGINT, Interrupt. [Switching to thread 636680.0x9b670] 0x762f6e39 in PulseEvent (Quit (gdb) thread apply all backtrace
Thread 6 (thread 636680.0x9b670): #0 0x762f6e39 in PulseEvent () from /cygdrive/c/Windows/system32/kernel32.dll #1 0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll #2 0x00000000 in ?? ()
Thread 5 (thread 636680.0x9b694): #0 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x76fa9254 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x762dc244 in WaitForSingleObjectEx () from /cygdrive/c/Windows/system32/kernel32.dll #3 0x000001e0 in ?? () #4 0x00000000 in ?? ()
Thread 4 (thread 636680.0x9b020): #0 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x76fa9254 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x762dc244 in WaitForSingleObjectEx () from /cygdrive/c/Windows/system32/kernel32.dll #3 0x000001fc in ?? () #4 0x00000000 in ?? ()
Thread 3 (thread 636680.0x9b7d4): #0 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x76fa8c74 in ntdll!ZwReadFile () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x762d046b in ReadFile () from /cygdrive/c/Windows/system32/kernel32.dll #3 0x00000110 in ?? () #4 0x00000000 in ?? ()
Thread 1 (thread 636680.0x9b5c0): #0 0x00411232 in ?? () #1 0x00fb22c0 in ?? () #2 0x00229354 in ?? () #3 0x00229368 in ?? () #4 0x00407538 in ?? () #5 0x01971f27 in ?? () #6 0x010e16bc in ?? () #7 0x002295cc in ?? () #8 0x01088553 in ?? () #9 0x01088553 in ?? () #10 0x01088551 in ?? () #11 0x00229a08 in ?? () #12 0x00403771 in ?? () #13 0x002295c0 in ?? () #14 0x01088551 in ?? () #15 0x01088551 in ?? () #16 0x00229de8 in ?? () #17 0x00000000 in ?? () #0 0x762f6e39 in PulseEvent () from /cygdrive/c/Windows/system32/kernel32.dll
Looks like bjam.exe is missing debug symbols. Is there a way to build a debug bjam.exe, perhaps using jam/src/build.sh?
Now that you mention it, adding --debug option to jam/src/build.sh might help, indeed. I think that it will be built to a separate dir, bin.something.debug, not bin.something as usual. - Volodya
Vladimir Prus wrote:
Eric Niebler wrote:
Looks like bjam.exe is missing debug symbols. Is there a way to build a debug bjam.exe, perhaps using jam/src/build.sh?
Now that you mention it, adding --debug option to jam/src/build.sh might help, indeed. I think that it will be built to a separate dir, bin.something.debug, not bin.something as usual.
Well, that's an improvement. Backtrace attached. I hope this is useful. -- Eric Niebler BoostPro Computing http://www.boostpro.com ericne@ericne-xps ~/boost/org/boost_1_39_0_beta1 $ gdb --args ./bjam.exe --help GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) run Starting program: /home/ericne/boost/org/boost_1_39_0_beta1/bjam.exe --help [New thread 636000.0x9b138] [New thread 636000.0x9b05c] [New thread 636000.0x9b530] Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17 [New thread 636000.0x9b29c] [New thread 636000.0x9b2c0] [New thread 636000.0x99338] Program received signal SIGINT, Interrupt. [Switching to thread 636000.0x99338] 0x762f6e39 in PulseEvent (Quit (gdb) thread apply all backtrace Thread 6 (thread 636000.0x99338): #0 0x762f6e39 in PulseEvent () from /cygdrive/c/Windows/system32/kernel32.dll #1 0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll #2 0x00000000 in ?? () Thread 5 (thread 636000.0x9b2c0): #0 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x76fa9254 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x762dc244 in WaitForSingleObjectEx () from /cygdrive/c/Windows/system32/kernel32.dll #3 0x000001dc in ?? () #4 0x00000000 in ?? () Thread 4 (thread 636000.0x9b29c): #0 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x76fa9254 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x762dc244 in WaitForSingleObjectEx () from /cygdrive/c/Windows/system32/kernel32.dll #3 0x000001fc in ?? () #4 0x00000000 in ?? () Thread 3 (thread 636000.0x9b530): #0 0x76fa9a94 in ntdll!LdrAccessResource () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x76fa8c74 in ntdll!ZwReadFile () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x762d046b in ReadFile () from /cygdrive/c/Windows/system32/kernel32.dll #3 0x00000110 in ?? () #4 0x00000000 in ?? () Thread 1 (thread 636000.0x9b138): #0 0x610defa1 in strlen () from /usr/bin/cygwin1.dll #1 0x00411725 in assert_invariants (self=0x228c30) at strings.c:30 #2 0x00411b3c in string_append_range (self=0x228c30, start=0x2291af "", finish=0x2291af "") at strings.c:143 #3 0x00403640 in var_expand (l=0x0, in=0x2291af "", end=0x2291af "", lol=0x229918, cancopyin=0) at expand.c:161 #4 0x00403821 in var_expand (l=0x0, in=0x11320be "", end=0x11320be "", lol=0x229918, cancopyin=1) at expand.c:246 #5 0x00401b5f in compile_list (parse=0x1134008, frame=0x229910) at compile.c:421 #6 0x0040c3f4 in parse_evaluate (p=0x1134008, frame=0x229910) at parse.c:131 #7 0x00402a61 in compile_set (parse=0x11340c8, frame=0x229910) at compile.c:1180 #8 0x0040c3f4 in parse_evaluate (p=0x11340c8, frame=0x229910) at parse.c:131 #9 0x00401806 in compile_if (p=0x1134128, frame=0x229910) at compile.c:288 #10 0x0040c3f4 in parse_evaluate (p=0x1134128, frame=0x229910) at parse.c:131 #11 0x004029cb in compile_rules (parse=0x1134128, frame=0x229910) at compile.c:1145 #12 0x0040c3f4 in parse_evaluate (p=0x1134158, frame=0x229910) at parse.c:131 #13 0x00401884 in compile_while (p=0x1134188, frame=0x229910) at compile.c:302 #14 0x0040c3f4 in parse_evaluate (p=0x1134188, frame=0x229910) at parse.c:131 #15 0x0040299e in compile_rules (parse=0x1134ac8, frame=0x229910) at compile.c:1143 #16 0x0040c3f4 in parse_evaluate (p=0x1134ac8, frame=0x229910) at parse.c:131 #17 0x00401c73 in compile_local (parse=0x1134af8, frame=0x229910) at compile.c:462 #18 0x0040c3f4 in parse_evaluate (p=0x1134af8, frame=0x229910) at parse.c:131 #19 0x00402837 in evaluate_rule (rulename=0x11339a8 "extract-token", frame=0x229910) at compile.c:1069 #20 0x00401df5 in compile_rule (parse=0x1138fa0, frame=0x229dd0) at compile.c:541 #21 0x0040c3f4 in parse_evaluate (p=0x1138fa0, frame=0x229dd0) at parse.c:131 #22 0x004012c7 in compile_append (parse=0x1138fd0, frame=0x229dd0) at compile.c:125 #23 0x0040c3f4 in parse_evaluate (p=0x1138fd0, frame=0x229dd0) at parse.c:131 #24 0x00402a79 in compile_set (parse=0x1139000, frame=0x229dd0) at compile.c:1181 #25 0x0040c3f4 in parse_evaluate (p=0x1139000, frame=0x229dd0) at parse.c:131 #26 0x0040299e in compile_rules (parse=0x113a758, frame=0x229dd0) at compile.c:1143 ---Type <return> to continue, or q <return> to quit--- #27 0x0040c3f4 in parse_evaluate (p=0x113a7e8, frame=0x229dd0) at parse.c:131 #28 0x00401c73 in compile_local (parse=0x113a818, frame=0x229dd0) at compile.c:462 #29 0x0040c3f4 in parse_evaluate (p=0x113a818, frame=0x229dd0) at parse.c:131 #30 0x00401c73 in compile_local (parse=0x113a848, frame=0x229dd0) at compile.c:462 #31 0x0040c3f4 in parse_evaluate (p=0x113a848, frame=0x229dd0) at parse.c:131 #32 0x00401c73 in compile_local (parse=0x113a878, frame=0x229dd0) at compile.c:462 #33 0x0040c3f4 in parse_evaluate (p=0x113a878, frame=0x229dd0) at parse.c:131 #34 0x00401884 in compile_while (p=0x113a8a8, frame=0x229dd0) at compile.c:302 #35 0x0040c3f4 in parse_evaluate (p=0x113a8a8, frame=0x229dd0) at parse.c:131 #36 0x0040299e in compile_rules (parse=0x113afb0, frame=0x229dd0) at compile.c:1143 #37 0x0040c3f4 in parse_evaluate (p=0x113afb0, frame=0x229dd0) at parse.c:131 #38 0x00401c73 in compile_local (parse=0x113afe0, frame=0x229dd0) at compile.c:462 #39 0x0040c3f4 in parse_evaluate (p=0x113afe0, frame=0x229dd0) at parse.c:131 #40 0x004029cb in compile_rules (parse=0x113afe0, frame=0x229dd0) at compile.c:1145 #41 0x0040c3f4 in parse_evaluate (p=0x113b040, frame=0x229dd0) at parse.c:131 #42 0x00401c73 in compile_local (parse=0x113b070, frame=0x229dd0) at compile.c:462 #43 0x0040c3f4 in parse_evaluate (p=0x113b070, frame=0x229dd0) at parse.c:131 #44 0x00401c73 in compile_local (parse=0x113b0a0, frame=0x229dd0) at compile.c:462 #45 0x0040c3f4 in parse_evaluate (p=0x113b0a0, frame=0x229dd0) at parse.c:131 #46 0x00402837 in evaluate_rule (rulename=0x1135d60 "scan-rule-arguments", frame=0x229dd0) at compile.c:1069 #47 0x00401df5 in compile_rule (parse=0x1135e68, frame=0x22a1f0) at compile.c:541 #48 0x0040c3f4 in parse_evaluate (p=0x1135e68, frame=0x22a1f0) at parse.c:131 #49 0x004012c7 in compile_append (parse=0x1135e98, frame=0x22a1f0) at compile.c:125 #50 0x0040c3f4 in parse_evaluate (p=0x1135e98, frame=0x22a1f0) at parse.c:131 #51 0x00401dc3 in compile_rule (parse=0x1135f28, frame=0x22a1f0) at compile.c:538 #52 0x0040c3f4 in parse_evaluate (p=0x1135f28, frame=0x22a1f0) at parse.c:131 #53 0x0040299e in compile_rules (parse=0x1137350, frame=0x22a1f0) at compile.c:1143 #54 0x0040c3f4 in parse_evaluate (p=0x11373b0, frame=0x22a1f0) at parse.c:131 #55 0x00401c73 in compile_local (parse=0x11373e0, frame=0x22a1f0) at compile.c:462 #56 0x0040c3f4 in parse_evaluate (p=0x11373e0, frame=0x22a1f0) at parse.c:131 #57 0x004029cb in compile_rules (parse=0x11373e0, frame=0x22a1f0) at compile.c:1145 #58 0x0040c3f4 in parse_evaluate (p=0x1137410, frame=0x22a1f0) at parse.c:131 #59 0x00401c73 in compile_local (parse=0x1137440, frame=0x22a1f0) at compile.c:462 #60 0x0040c3f4 in parse_evaluate (p=0x1137440, frame=0x22a1f0) at parse.c:131 #61 0x00401806 in compile_if (p=0x11374a0, frame=0x22a1f0) at compile.c:288 #62 0x0040c3f4 in parse_evaluate (p=0x11374a0, frame=0x22a1f0) at parse.c:131 #63 0x00401c73 in compile_local (parse=0x11374d0, frame=0x22a1f0) at compile.c:462 #64 0x0040c3f4 in parse_evaluate (p=0x11374d0, frame=0x22a1f0) at parse.c:131 #65 0x00402837 in evaluate_rule (rulename=0x1134b58 "scan-rule", frame=0x22a1f0) at compile.c:1069 #66 0x00401df5 in compile_rule (parse=0x1136968, frame=0x22a720) at compile.c:541 #67 0x0040c3f4 in parse_evaluate (p=0x1136968, frame=0x22a720) at parse.c:131 #68 0x004013c9 in compile_eval (parse=0x11369c8, frame=0x22a720) at compile.c:167 #69 0x0040c3f4 in parse_evaluate (p=0x11369c8, frame=0x22a720) at parse.c:131 #70 0x004017dd in compile_if (p=0x1137170, frame=0x22a720) at compile.c:284 #71 0x0040c3f4 in parse_evaluate (p=0x1137170, frame=0x22a720) at parse.c:131 #72 0x00401c73 in compile_local (parse=0x11371a0, frame=0x22a720) at compile.c:462 #73 0x0040c3f4 in parse_evaluate (p=0x11371a0, frame=0x22a720) at parse.c:131 #74 0x00401c73 in compile_local (parse=0x11371d0, frame=0x22a720) at compile.c:462 #75 0x0040c3f4 in parse_evaluate (p=0x11371d0, frame=0x22a720) at parse.c:131 #76 0x00401884 in compile_while (p=0x1137200, frame=0x22a720) at compile.c:302 #77 0x0040c3f4 in parse_evaluate (p=0x1137200, frame=0x22a720) at parse.c:131 #78 0x0040299e in compile_rules (parse=0x11372c0, frame=0x22a720) at compile.c:1143 #79 0x0040c3f4 in parse_evaluate (p=0x11372c0, frame=0x22a720) at parse.c:131 #80 0x00401c73 in compile_local (parse=0x11372f0, frame=0x22a720) at compile.c:462 #81 0x0040c3f4 in parse_evaluate (p=0x11372f0, frame=0x22a720) at parse.c:131 #82 0x00401c73 in compile_local (parse=0x1137320, frame=0x22a720) at compile.c:462 #83 0x0040c3f4 in parse_evaluate (p=0x1137320, frame=0x22a720) at parse.c:131 #84 0x004029cb in compile_rules (parse=0x1137320, frame=0x22a720) at compile.c:1145 ---Type <return> to continue, or q <return> to quit--- #85 0x0040c3f4 in parse_evaluate (p=0x11373b0, frame=0x22a720) at parse.c:131 #86 0x00401c73 in compile_local (parse=0x11373e0, frame=0x22a720) at compile.c:462 #87 0x0040c3f4 in parse_evaluate (p=0x11373e0, frame=0x22a720) at parse.c:131 #88 0x004029cb in compile_rules (parse=0x11373e0, frame=0x22a720) at compile.c:1145 #89 0x0040c3f4 in parse_evaluate (p=0x1137410, frame=0x22a720) at parse.c:131 #90 0x00401c73 in compile_local (parse=0x1137440, frame=0x22a720) at compile.c:462 #91 0x0040c3f4 in parse_evaluate (p=0x1137440, frame=0x22a720) at parse.c:131 #92 0x00401806 in compile_if (p=0x11374a0, frame=0x22a720) at compile.c:288 #93 0x0040c3f4 in parse_evaluate (p=0x11374a0, frame=0x22a720) at parse.c:131 #94 0x00401c73 in compile_local (parse=0x11374d0, frame=0x22a720) at compile.c:462 #95 0x0040c3f4 in parse_evaluate (p=0x11374d0, frame=0x22a720) at parse.c:131 #96 0x00402837 in evaluate_rule (rulename=0x1134b58 "scan-rule", frame=0x22a720) at compile.c:1069 #97 0x00401df5 in compile_rule (parse=0x113e960, frame=0x22ab60) at compile.c:541 #98 0x0040c3f4 in parse_evaluate (p=0x113e960, frame=0x22ab60) at parse.c:131 #99 0x004013c9 in compile_eval (parse=0x113e9c0, frame=0x22ab60) at compile.c:167 #100 0x0040c3f4 in parse_evaluate (p=0x113e9c0, frame=0x22ab60) at parse.c:131 #101 0x004017dd in compile_if (p=0x113fb20, frame=0x22ab60) at compile.c:284 #102 0x0040c3f4 in parse_evaluate (p=0x113fb20, frame=0x22ab60) at parse.c:131 #103 0x004029cb in compile_rules (parse=0x113fb20, frame=0x22ab60) at compile.c:1145 #104 0x0040c3f4 in parse_evaluate (p=0x113fbb0, frame=0x22ab60) at parse.c:131 #105 0x00401884 in compile_while (p=0x113fbe0, frame=0x22ab60) at compile.c:302 #106 0x0040c3f4 in parse_evaluate (p=0x113fbe0, frame=0x22ab60) at parse.c:131 #107 0x0040299e in compile_rules (parse=0x113fed8, frame=0x22ab60) at compile.c:1143 #108 0x0040c3f4 in parse_evaluate (p=0x113ff08, frame=0x22ab60) at parse.c:131 #109 0x00401c73 in compile_local (parse=0x113ff38, frame=0x22ab60) at compile.c:462 #110 0x0040c3f4 in parse_evaluate (p=0x113ff38, frame=0x22ab60) at parse.c:131 #111 0x00401c73 in compile_local (parse=0x113ff68, frame=0x22ab60) at compile.c:462 #112 0x0040c3f4 in parse_evaluate (p=0x113ff68, frame=0x22ab60) at parse.c:131 #113 0x00401c73 in compile_local (parse=0x113ff98, frame=0x22ab60) at compile.c:462 #114 0x0040c3f4 in parse_evaluate (p=0x113ff98, frame=0x22ab60) at parse.c:131 #115 0x00401c73 in compile_local (parse=0x113ffc8, frame=0x22ab60) at compile.c:462 #116 0x0040c3f4 in parse_evaluate (p=0x113ffc8, frame=0x22ab60) at parse.c:131 #117 0x004029cb in compile_rules (parse=0x113ffc8, frame=0x22ab60) at compile.c:1145 #118 0x0040c3f4 in parse_evaluate (p=0x113fff8, frame=0x22ab60) at parse.c:131 #119 0x00402837 in evaluate_rule (rulename=0x113d280 "scan-module", frame=0x22ab60) at compile.c:1069 #120 0x00401df5 in compile_rule (parse=0x1143648, frame=0x22adc0) at compile.c:541 #121 0x0040c3f4 in parse_evaluate (p=0x1143648, frame=0x22adc0) at parse.c:131 #122 0x004029cb in compile_rules (parse=0x1143648, frame=0x22adc0) at compile.c:1145 #123 0x0040c3f4 in parse_evaluate (p=0x11436d8, frame=0x22adc0) at parse.c:131 #124 0x00402837 in evaluate_rule (rulename=0x10e2940 "do-scan", frame=0x22adc0) at compile.c:1069 #125 0x00401df5 in compile_rule (parse=0x10e9220, frame=0x22b240) at compile.c:541 #126 0x0040c3f4 in parse_evaluate (p=0x10e9220, frame=0x22b240) at parse.c:131 #127 0x0040177f in compile_foreach (parse=0x10e9250, frame=0x22b240) at compile.c:260 #128 0x0040c3f4 in parse_evaluate (p=0x10e9250, frame=0x22b240) at parse.c:131 #129 0x0040299e in compile_rules (parse=0x10bab08, frame=0x22b240) at compile.c:1143 #130 0x0040c3f4 in parse_evaluate (p=0x10bab38, frame=0x22b240) at parse.c:131 #131 0x00401c73 in compile_local (parse=0x10bab68, frame=0x22b240) at compile.c:462 #132 0x0040c3f4 in parse_evaluate (p=0x10bab68, frame=0x22b240) at parse.c:131 #133 0x00401c73 in compile_local (parse=0x10bab98, frame=0x22b240) at compile.c:462 #134 0x0040c3f4 in parse_evaluate (p=0x10bab98, frame=0x22b240) at parse.c:131 #135 0x004029cb in compile_rules (parse=0x10bab98, frame=0x22b240) at compile.c:1145 #136 0x0040c3f4 in parse_evaluate (p=0x10b87f8, frame=0x22b240) at parse.c:131 #137 0x00401820 in compile_if (p=0x10b8828, frame=0x22b240) at compile.c:290 #138 0x0040c3f4 in parse_evaluate (p=0x10b8828, frame=0x22b240) at parse.c:131 #139 0x0040299e in compile_rules (parse=0x10c32b0, frame=0x22b240) at compile.c:1143 #140 0x0040c3f4 in parse_evaluate (p=0x10c32b0, frame=0x22b240) at parse.c:131 #141 0x00401c73 in compile_local (parse=0x10c32e0, frame=0x22b240) at compile.c:462 #142 0x0040c3f4 in parse_evaluate (p=0x10c32e0, frame=0x22b240) at parse.c:131 ---Type <return> to continue, or q <return> to quit--- #143 0x00402e69 in compile_switch (parse=0x10c32e0, frame=0x22b240) at compile.c:1329 #144 0x0040c3f4 in parse_evaluate (p=0x10be1a0, frame=0x22b240) at parse.c:131 #145 0x0040299e in compile_rules (parse=0x10ba380, frame=0x22b240) at compile.c:1143 #146 0x0040c3f4 in parse_evaluate (p=0x10ba380, frame=0x22b240) at parse.c:131 #147 0x00401c73 in compile_local (parse=0x10ba3b0, frame=0x22b240) at compile.c:462 #148 0x0040c3f4 in parse_evaluate (p=0x10ba3b0, frame=0x22b240) at parse.c:131 #149 0x004029cb in compile_rules (parse=0x10ba3b0, frame=0x22b240) at compile.c:1145 #150 0x0040c3f4 in parse_evaluate (p=0x10ba3e0, frame=0x22b240) at parse.c:131 #151 0x00402837 in evaluate_rule (rulename=0x10de9b0 "process", frame=0x22b240) at compile.c:1069 #152 0x00401df5 in compile_rule (parse=0x10d1a60, frame=0x22b500) at compile.c:541 #153 0x0040c3f4 in parse_evaluate (p=0x10d1a60, frame=0x22b500) at parse.c:131 #154 0x004012c7 in compile_append (parse=0x10d1a90, frame=0x22b500) at compile.c:125 #155 0x0040c3f4 in parse_evaluate (p=0x10d1a90, frame=0x22b500) at parse.c:131 #156 0x004019e5 in evaluate_in_module (module_name=0x1048368 "--help", p=0x10d1a90, frame=0x22b500) at compile.c:367 #157 0x00401a6c in compile_module (p=0x10d1ac0, frame=0x22b500) at compile.c:384 #158 0x0040c3f4 in parse_evaluate (p=0x10d1ac0, frame=0x22b500) at parse.c:131 #159 0x00402837 in evaluate_rule (rulename=0x10c8c70 "modules.call-in", frame=0x22b500) at compile.c:1069 #160 0x00401df5 in compile_rule (parse=0x10e19b0, frame=0x22bc30) at compile.c:541 #161 0x0040c3f4 in parse_evaluate (p=0x10e19b0, frame=0x22bc30) at parse.c:131 #162 0x004012c7 in compile_append (parse=0x10e19e0, frame=0x22bc30) at compile.c:125 #163 0x0040c3f4 in parse_evaluate (p=0x10e19e0, frame=0x22bc30) at parse.c:131 #164 0x00402a79 in compile_set (parse=0x10e1a10, frame=0x22bc30) at compile.c:1181 #165 0x0040c3f4 in parse_evaluate (p=0x10e1a10, frame=0x22bc30) at parse.c:131 #166 0x00401806 in compile_if (p=0x10e1a70, frame=0x22bc30) at compile.c:288 #167 0x0040c3f4 in parse_evaluate (p=0x10e1a70, frame=0x22bc30) at parse.c:131 #168 0x004029cb in compile_rules (parse=0x10e1a70, frame=0x22bc30) at compile.c:1145 #169 0x0040c3f4 in parse_evaluate (p=0x10e1aa0, frame=0x22bc30) at parse.c:131 #170 0x00401c73 in compile_local (parse=0x10e1ad0, frame=0x22bc30) at compile.c:462 #171 0x0040c3f4 in parse_evaluate (p=0x10e1ad0, frame=0x22bc30) at parse.c:131 #172 0x00401c73 in compile_local (parse=0x10e1b00, frame=0x22bc30) at compile.c:462 #173 0x0040c3f4 in parse_evaluate (p=0x10e1b00, frame=0x22bc30) at parse.c:131 #174 0x00401806 in compile_if (p=0x10e1b60, frame=0x22bc30) at compile.c:288 #175 0x0040c3f4 in parse_evaluate (p=0x10e1b60, frame=0x22bc30) at parse.c:131 #176 0x00401c73 in compile_local (parse=0x10e1b90, frame=0x22bc30) at compile.c:462 #177 0x0040c3f4 in parse_evaluate (p=0x10e1b90, frame=0x22bc30) at parse.c:131 #178 0x00401c73 in compile_local (parse=0x10e1bc0, frame=0x22bc30) at compile.c:462 #179 0x0040c3f4 in parse_evaluate (p=0x10e1bc0, frame=0x22bc30) at parse.c:131 #180 0x004029cb in compile_rules (parse=0x10e1bc0, frame=0x22bc30) at compile.c:1145 #181 0x0040c3f4 in parse_evaluate (p=0x10e1c20, frame=0x22bc30) at parse.c:131 #182 0x00401c73 in compile_local (parse=0x10e1c50, frame=0x22bc30) at compile.c:462 #183 0x0040c3f4 in parse_evaluate (p=0x10e1c50, frame=0x22bc30) at parse.c:131 #184 0x00401c73 in compile_local (parse=0x10e1c80, frame=0x22bc30) at compile.c:462 #185 0x0040c3f4 in parse_evaluate (p=0x10e1c80, frame=0x22bc30) at parse.c:131 #186 0x00401c73 in compile_local (parse=0x10e1cb0, frame=0x22bc30) at compile.c:462 #187 0x0040c3f4 in parse_evaluate (p=0x10e1cb0, frame=0x22bc30) at parse.c:131 #188 0x00401c73 in compile_local (parse=0x10e1ce0, frame=0x22bc30) at compile.c:462 #189 0x0040c3f4 in parse_evaluate (p=0x10e1ce0, frame=0x22bc30) at parse.c:131 #190 0x00401806 in compile_if (p=0x10e1d40, frame=0x22bc30) at compile.c:288 #191 0x0040c3f4 in parse_evaluate (p=0x10e1d40, frame=0x22bc30) at parse.c:131 #192 0x004029cb in compile_rules (parse=0x10e1d40, frame=0x22bc30) at compile.c:1145 #193 0x0040c3f4 in parse_evaluate (p=0x10e1da0, frame=0x22bc30) at parse.c:131 #194 0x00401c73 in compile_local (parse=0x10e1dd0, frame=0x22bc30) at compile.c:462 #195 0x0040c3f4 in parse_evaluate (p=0x10e1dd0, frame=0x22bc30) at parse.c:131 #196 0x00401884 in compile_while (p=0x10e1e00, frame=0x22bc30) at compile.c:302 #197 0x0040c3f4 in parse_evaluate (p=0x10e1e00, frame=0x22bc30) at parse.c:131 #198 0x0040299e in compile_rules (parse=0x10e1ec0, frame=0x22bc30) at compile.c:1143 #199 0x0040c3f4 in parse_evaluate (p=0x10e1ec0, frame=0x22bc30) at parse.c:131 ---Type <return> to continue, or q <return> to quit--- #200 0x00401c73 in compile_local (parse=0x10e1ef0, frame=0x22bc30) at compile.c:462 #201 0x0040c3f4 in parse_evaluate (p=0x10e1ef0, frame=0x22bc30) at parse.c:131 #202 0x00401c73 in compile_local (parse=0x10e1f20, frame=0x22bc30) at compile.c:462 #203 0x0040c3f4 in parse_evaluate (p=0x10e1f20, frame=0x22bc30) at parse.c:131 #204 0x00401c73 in compile_local (parse=0x10e1f50, frame=0x22bc30) at compile.c:462 #205 0x0040c3f4 in parse_evaluate (p=0x10e1f50, frame=0x22bc30) at parse.c:131 #206 0x00401c73 in compile_local (parse=0x10e1f80, frame=0x22bc30) at compile.c:462 #207 0x0040c3f4 in parse_evaluate (p=0x10e1f80, frame=0x22bc30) at parse.c:131 #208 0x00402837 in evaluate_rule (rulename=0x10c7ef8 "option.process", frame=0x22bc30) at compile.c:1069 #209 0x00401df5 in compile_rule (parse=0x10c7fa0, frame=0x22c120) at compile.c:541 #210 0x0040c3f4 in parse_evaluate (p=0x10c7fa0, frame=0x22c120) at parse.c:131 #211 0x004012c7 in compile_append (parse=0x10c7fd0, frame=0x22c120) at compile.c:125 #212 0x0040c3f4 in parse_evaluate (p=0x10c7fd0, frame=0x22c120) at parse.c:131 #213 0x00401b9b in compile_local (parse=0x10af778, frame=0x22c120) at compile.c:438 #214 0x0040c3f4 in parse_evaluate (p=0x10af778, frame=0x22c120) at parse.c:131 #215 0x004029cb in compile_rules (parse=0x10af778, frame=0x22c120) at compile.c:1145 #216 0x0040c3f4 in parse_evaluate (p=0x10b49a8, frame=0x22c120) at parse.c:131 #217 0x00401c73 in compile_local (parse=0x10b49d8, frame=0x22c120) at compile.c:462 #218 0x0040c3f4 in parse_evaluate (p=0x10b49d8, frame=0x22c120) at parse.c:131 #219 0x004029cb in compile_rules (parse=0x10b49d8, frame=0x22c120) at compile.c:1145 #220 0x0040c3f4 in parse_evaluate (p=0x10b4a08, frame=0x22c120) at parse.c:131 #221 0x00401c73 in compile_local (parse=0x10b4a38, frame=0x22c120) at compile.c:462 #222 0x0040c3f4 in parse_evaluate (p=0x10b4a38, frame=0x22c120) at parse.c:131 #223 0x004029cb in compile_rules (parse=0x10b4a38, frame=0x22c120) at compile.c:1145 #224 0x0040c3f4 in parse_evaluate (p=0x10b4a68, frame=0x22c120) at parse.c:131 #225 0x0040c24c in parse_file ( f=0x10b1d68 "/home/ericne/boost/org/boost_1_39_0_beta1/tools/build/v2/kernel/bootstrap.jam", frame=0x22c120) at parse.c:53 #226 0x0040195d in compile_include (parse=0x10b1cd0, frame=0x22c120) at compile.c:346 #227 0x0040c3f4 in parse_evaluate (p=0x10b1cd0, frame=0x22c120) at parse.c:131 #228 0x004029cb in compile_rules (parse=0x10b1cd0, frame=0x22c120) at compile.c:1145 #229 0x0040c3f4 in parse_evaluate (p=0x10b1d00, frame=0x22c120) at parse.c:131 #230 0x0040c24c in parse_file ( f=0x10b0750 "/home/ericne/boost/org/boost_1_39_0_beta1/tools/build/v2/bootstrap.jam", frame=0x22c120) at parse.c:53 #231 0x0040195d in compile_include (parse=0x10540c8, frame=0x22c120) at compile.c:346 #232 0x0040c3f4 in parse_evaluate (p=0x10540c8, frame=0x22c120) at parse.c:131 #233 0x004029cb in compile_rules (parse=0x10540c8, frame=0x22c120) at compile.c:1145 #234 0x0040c3f4 in parse_evaluate (p=0x1054158, frame=0x22c120) at parse.c:131 #235 0x00401c73 in compile_local (parse=0x1054188, frame=0x22c120) at compile.c:462 #236 0x0040c3f4 in parse_evaluate (p=0x1054188, frame=0x22c120) at parse.c:131 #237 0x004029cb in compile_rules (parse=0x1054188, frame=0x22c120) at compile.c:1145 #238 0x0040c3f4 in parse_evaluate (p=0x1054218, frame=0x22c120) at parse.c:131 #239 0x00402837 in evaluate_rule (rulename=0x1051d20 "boost-build", frame=0x22c120) at compile.c:1069 #240 0x00401df5 in compile_rule (parse=0x10b01f0, frame=0x22c370) at compile.c:541 #241 0x0040c3f4 in parse_evaluate (p=0x10b01f0, frame=0x22c370) at parse.c:131 #242 0x004029cb in compile_rules (parse=0x10b01f0, frame=0x22c370) at compile.c:1145 #243 0x0040c3f4 in parse_evaluate (p=0x10b0280, frame=0x22c370) at parse.c:131 #244 0x0040c24c in parse_file ( f=0x10b42f0 "/home/ericne/boost/org/boost_1_39_0_beta1/boost-build.jam", frame=0x22c370) at parse.c:53 #245 0x0040195d in compile_include (parse=0x10564b8, frame=0x22c370) at compile.c:346 #246 0x0040c3f4 in parse_evaluate (p=0x10564b8, frame=0x22c370) at parse.c:131 #247 0x0040299e in compile_rules (parse=0x10571a0, frame=0x22c370) at compile.c:1143 #248 0x0040c3f4 in parse_evaluate (p=0x1057230, frame=0x22c370) at parse.c:131 #249 0x00401c73 in compile_local (parse=0x1057260, frame=0x22c370) at compile.c:462 #250 0x0040c3f4 in parse_evaluate (p=0x1057260, frame=0x22c370) at parse.c:131 ---Type <return> to continue, or q <return> to quit--- #251 0x00401c73 in compile_local (parse=0x1057290, frame=0x22c370) at compile.c:462 #252 0x0040c3f4 in parse_evaluate (p=0x1057290, frame=0x22c370) at parse.c:131 #253 0x00401806 in compile_if (p=0x10ae1d8, frame=0x22c370) at compile.c:288 #254 0x0040c3f4 in parse_evaluate (p=0x10ae1d8, frame=0x22c370) at parse.c:131 #255 0x004029cb in compile_rules (parse=0x10ae1d8, frame=0x22c370) at compile.c:1145 #256 0x0040c3f4 in parse_evaluate (p=0x1045300, frame=0x22c370) at parse.c:131 #257 0x0040c24c in parse_file (f=0x41bd9f "+", frame=0x22c370) at parse.c:53 #258 0x00406f15 in main (argc=1, argv=0x104226c, arg_environ=0x1040090) at jam.c:459 #0 0x762f6e39 in PulseEvent () from /cygdrive/c/Windows/system32/kernel32.dll (gdb)
(Resending...) Beman Dawes wrote:
The beta candidate files are up at http://boost.cowic.de/rc/
Before pushing these out to SourceForge, it would be great if a few Boosters could download and try them out as a final QA check. Post your experiences here.
I still have the same problem as before on cygwin. I run ./bootstrap.sh and then ./bjam --help and get this: Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17 ... and then bjam just hangs with the cpu pegged at 100%. I tried ash.exe and rebaseall like someone suggested, but it hasn't helped. Can anybody else reproduce this? FWIW, a plain "./bjam" doesn't hang and seems to kick off a proper build. Very odd. -- Eric Niebler BoostPro Computing http://www.boostpro.com
I still have the same problem as before on cygwin. I run ./bootstrap.sh and then ./bjam --help and get this:
Boost.Build V2 (Milestone 12) Boost.Jam 03.1.17
... and then bjam just hangs with the cpu pegged at 100%. I tried ash.exe and rebaseall like someone suggested, but it hasn't helped. Can anybody else reproduce this?
It still works fine for me. What does bjam do between when it prints that out and prints out the help? I do notice a distinct pause when I run it. --Jeffrey Bosboom
1. ./bootstrap.sh < getting started says to do this ./bootstrap.sh: line 188: ./tools/jam/src/build.sh: Permission denied 2. sh boostrap.sh Building Boost.Jam with toolset ... ./bootstrap.sh: line 220: ./bootstrap/jam0: No such file or directory tools/jam/src//bjam cp: cannot stat `./tools/jam/src//bjam': No such file or directory Detecting Python version... 2.5 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... /usr Generating Boost.Build configuration in project-config.jam... Bootstrapping is done. To build, run: ./bjam << again, incorrect ./bjam --help bash: ./bjam: No such file or directory 3. sh BUILD project-config.jam:10: syntax error at keyword in project-config.jam:11: syntax error at keyword { project-config.jam:13: syntax error at keyword } warning: No toolsets are configured. Here is BUILD (which I've used for many previous boost versions): bjam -sICU_PATH=/usr -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 -- layout=system threading=single,multi stage
Vladimir Prus wrote:
Neal Becker wrote:
1. ./bootstrap.sh < getting started says to do this ./bootstrap.sh: line 188: ./tools/jam/src/build.sh: Permission denied
Uhm -- something has stripped 'x' bit? What package are you using (specific file name)?
I used the 7zip package, with 7x x ...
Neal Becker wrote:
Vladimir Prus wrote:
Neal Becker wrote:
1. ./bootstrap.sh < getting started says to do this ./bootstrap.sh: line 188: ./tools/jam/src/build.sh: Permission denied
Uhm -- something has stripped 'x' bit? What package are you using (specific file name)?
I used the 7zip package, with 7x x ...
Hmm. I have only program called 7zr, and after running it I don't have x bits sets -- even bootstrap.sh is not executable. So, maybe, 7z archives are just not suitable for Linux? Can anybody comment? - Volodya
OK, try again. This time clean .tar.bz2. sh BUILD warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include /usr/local/src/boost_1_39_0_beta1/tools/build/v2/build/virtual- target.jam:1056: in virtual-target.register-actual-name from module virtual- target error: Duplicate name of actual target: <pstage/lib>libboost_date_time.so.1.39.0 error: previous virtual target { common%common.copy- libboost_date_time.so.1.39.0.SHARED_LIB { gcc%gcc.link.dll- libboost_date_time.so.1.39.0.SHARED_LIB { gcc%gcc.compile.c++- gregorian/greg_month.o.OBJ { gregorian/greg_month.cpp.CPP } } { gcc%gcc.compile.c++-gregorian/greg_weekday.o.OBJ { gregorian/greg_weekday.cpp.CPP } } { gcc%gcc.compile.c++- gregorian/date_generators.o.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy- libboost_date_time.so.1.39.0.SHARED_LIB { gcc%gcc.link.dll- libboost_date_time.so.1.39.0.SHARED_LIB { gcc%gcc.compile.c++- gregorian/greg_month.o.OBJ { gregorian/greg_month.cpp.CPP } } { gcc%gcc.compile.c++-gregorian/greg_weekday.o.OBJ { gregorian/greg_weekday.cpp.CPP } } { gcc%gcc.compile.c++- gregorian/date_generators.o.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: added properties: <threading>multi error: removed properties: <threading>single /usr/local/src/boost_1_39_0_beta1/tools/build/v2/build/virtual- target.jam:480: in actualize-no-scanner from module object(file-target)@4671 /usr/local/src/boost_1_39_0_beta1/tools/build/v2/build/virtual- target.jam:130: in object(file-target)@4671.actualize from module object(file-target)@4671 /usr/local/src/boost_1_39_0_beta1/tools/build/v2/build-system.jam:713: in load from module build-system /usr/local/src/boost_1_39_0_beta1/tools/build/v2/kernel/modules.jam:283: in import from module modules /usr/local/src/boost_1_39_0_beta1/tools/build/v2/kernel/bootstrap.jam:138: in boost-build from module /usr/local/src/boost_1_39_0_beta1/boost-build.jam:16: in module scope from module
Neal Becker wrote:
OK, try again. This time clean .tar.bz2.
sh BUILD warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include /usr/local/src/boost_1_39_0_beta1/tools/build/v2/build/virtual- target.jam:1056: in virtual-target.register-actual-name from module virtual- target error: Duplicate name of actual target: <pstage/lib>libboost_date_time.so.1.39.0 ... error: added properties: <threading>multi error: removed properties: <threading>single
This is expected. In 1.39, --layout=system does not use any decoration of the names, so that to match it's intended purpose -- system integrators. You are trying to build both ST and MT variants and put both to 'stage' directory, which results in name clash. I can introduce new --layout=tagged that would encode threading and variant into the name. What do you think? - Volodya
Vladimir Prus wrote:
Neal Becker wrote:
OK, try again. This time clean .tar.bz2.
sh BUILD warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include /usr/local/src/boost_1_39_0_beta1/tools/build/v2/build/virtual- target.jam:1056: in virtual-target.register-actual-name from module virtual- target error: Duplicate name of actual target: <pstage/lib>libboost_date_time.so.1.39.0 ... error: added properties: <threading>multi error: removed properties: <threading>single
This is expected. In 1.39, --layout=system does not use any decoration of the names, so that to match it's intended purpose -- system integrators. You are trying to build both ST and MT variants and put both to 'stage' directory, which results in name clash.
I can introduce new --layout=tagged that would encode threading and variant into the name. What do you think?
I'm expecting to match previous behaviour, which is to produce: e.g.: libboost_date_time-mt.so libboost_date_time.so The name includes threading only.
Neal Becker wrote:
Vladimir Prus wrote:
Neal Becker wrote:
OK, try again. This time clean .tar.bz2.
sh BUILD warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include /usr/local/src/boost_1_39_0_beta1/tools/build/v2/build/virtual- target.jam:1056: in virtual-target.register-actual-name from module virtual- target error: Duplicate name of actual target: <pstage/lib>libboost_date_time.so.1.39.0 ... error: added properties: <threading>multi error: removed properties: <threading>single
This is expected. In 1.39, --layout=system does not use any decoration of the names, so that to match it's intended purpose -- system integrators. You are trying to build both ST and MT variants and put both to 'stage' directory, which results in name clash.
I can introduce new --layout=tagged that would encode threading and variant into the name. What do you think?
I'm expecting to match previous behaviour, which is to produce: e.g.: libboost_date_time-mt.so libboost_date_time.so
The name includes threading only.
Please try either SVN HEAD or current state of release branch, with --layout=tagged. It should behave as --layout=system used to. - Volodya
Vladimir Prus wrote:
Neal Becker wrote:
Vladimir Prus wrote:
Neal Becker wrote:
OK, try again. This time clean .tar.bz2.
sh BUILD warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include /usr/local/src/boost_1_39_0_beta1/tools/build/v2/build/virtual- target.jam:1056: in virtual-target.register-actual-name from module virtual- target error: Duplicate name of actual target: <pstage/lib>libboost_date_time.so.1.39.0 ... error: added properties: <threading>multi error: removed properties: <threading>single
This is expected. In 1.39, --layout=system does not use any decoration of the names, so that to match it's intended purpose -- system integrators. You are trying to build both ST and MT variants and put both to 'stage' directory, which results in name clash.
I can introduce new --layout=tagged that would encode threading and variant into the name. What do you think?
I'm expecting to match previous behaviour, which is to produce: e.g.: libboost_date_time-mt.so libboost_date_time.so
The name includes threading only.
Please try either SVN HEAD or current state of release branch, with --layout=tagged. It should behave as --layout=system used to.
- Volodya
Thanks. I poked around http://svn.boost.org/svn/boost/ but couldn't figure out how to get the current release branch (1.39.0 I suppose). How do I get it?
Neal Becker wrote:
Vladimir Prus wrote:
Neal Becker wrote:
Vladimir Prus wrote:
Neal Becker wrote:
OK, try again. This time clean .tar.bz2.
sh BUILD warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Note: Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include /usr/local/src/boost_1_39_0_beta1/tools/build/v2/build/virtual- target.jam:1056: in virtual-target.register-actual-name from module virtual- target error: Duplicate name of actual target: <pstage/lib>libboost_date_time.so.1.39.0 ... error: added properties: <threading>multi error: removed properties: <threading>single
This is expected. In 1.39, --layout=system does not use any decoration of the names, so that to match it's intended purpose -- system integrators. You are trying to build both ST and MT variants and put both to 'stage' directory, which results in name clash.
I can introduce new --layout=tagged that would encode threading and variant into the name. What do you think?
I'm expecting to match previous behaviour, which is to produce: e.g.: libboost_date_time-mt.so libboost_date_time.so
The name includes threading only.
Please try either SVN HEAD or current state of release branch, with --layout=tagged. It should behave as --layout=system used to.
- Volodya
Thanks. I poked around http://svn.boost.org/svn/boost/ but couldn't figure out how to get the current release branch (1.39.0 I suppose). How do I get it?
svn co https://svn.boost.org/svn/boost/branches/release If you already have trunk checkout you might want to switch it: svn sw https://svn.boost.org/svn/boost/branches/release but I am not sure this is gonna be much faster. - Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (9)
-
Beman Dawes -
Eric Niebler -
Eric Niebler -
jbosboom＠uci.edu -
Neal Becker -
Robert Ramey -
Ruediger Berlich -
troy d. straszheim -
Vladimir Prus