[boost] [1.39.0] Beta candidate
Beman Dawes
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
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
troy d. straszheim
> 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:
A backtrace would be helpful...
-t
Ruediger Berlich
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:
>
>
http://sodium.resophonic.com/git/boost/diff/libs/serialization/src/extended_type_info_typeid.cpp?h=release&id=c7e977901094b902b12937dda9994593dbafdc43
>
> 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.
troy d. straszheim
> 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
Robert Ramey
> 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
Eric Niebler
> 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
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
jbos...@uci.edu
> 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
Vladimir Prus
> 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
Neal Becker
./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
> 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)?
- Volodya
Neal Becker
> 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 ...
Vladimir Prus
> 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
Neal Becker
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
Eric Niebler
> 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
Vladimir Prus
Try:
thread apply all backtrace
to get backtrace in all threads. I'm not overly optimistic :-(
- Volodya
Eric Niebler
> 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
Vladimir Prus
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
Eric Niebler
> Eric Niebler wrote:
>> 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.
Vladimir Prus
> 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
Neal Becker
> 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.
Vladimir Prus
Please try either SVN HEAD or current state of release branch, with --layout=tagged.
It should behave as --layout=system used to.
- Volodya
Neal Becker
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?
Vladimir Prus
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