Problems installing uBLAS using HP-UX/G++
I would like to install parts of Boost, for now the uBLAS and smart pointer libraries, on a workstation running HP-UX 11.22. I'm using gcc 3.4.3, not HP's C++ compiler. bjam seems to build okay, but when I try to use bjam to install just the uBLAS library using the command ~/bin/bjam "-sTOOLS=gcc" --prefix=/home/dgarza/ --builddir=/tmp/build-scratch/ --with-ublas it tries to build Boost.Python, Boost.Regex, and possibly other libraries, then gives the message ...found 3330 targets... then quits saying nothing else. I know it's trying to build Python and Regex because it prints messages about building those libraries, I don't know what else it's trying to build. When I add "stage" to the end of the command, bjam tries to build Python and Regex, then says don't know how to make stage ...found 1 target... ...can't find 1 target... When I try "install" instead of "stage," bjam seems to try installing everything. It ends with the message ...updated 3571 targets... The bjam documentation and help say the --with- option should make bjam just build/stage/install the specified library, but that isn't what is happening. Is there a list of dependencies for the different parts of Boost? Does uBLAS actually require Python and Regex? Related to this, would it be possible to provide a list of the names acceptable in the --with- and --without- options? Since uBLAS is under numeric I wasn't sure if the appropriate library name was numeric, ublas, uBLAS, numeric/ublas, etc. I tried to see if I could find a list of names somewhere but I nothing jumped out in the files I looked at. Does it just go by directory names? Thanks, David
I would like to install parts of Boost, for now the uBLAS and smart pointer libraries, on a workstation running HP-UX 11.22. I'm using gcc 3.4.3, not HP's C++ compiler.
bjam seems to build okay, but when I try to use bjam to install just the uBLAS library using the command
ublas is a header only library so there's no need to build anything to use it. You should be able to just install the headers though without building anything if that's what you want to do. Rene: I think you wrote the install code any ideas? Or are we moving to bbv2 anyway? :-) John.
John Maddock wrote:
I would like to install parts of Boost, for now the uBLAS and smart pointer libraries, on a workstation running HP-UX 11.22. I'm using gcc 3.4.3, not HP's C++ compiler.
bjam seems to build okay, but when I try to use bjam to install just the uBLAS library using the command
ublas is a header only library so there's no need to build anything to use it. You should be able to just install the headers though without building anything if that's what you want to do.
ublas is a header-only library, but it does have dependencies on other boost libraries. I'm guessing since I've been able to play with ublas a little already the dependencies are also header-only libraries--I definitely don't have any libraries built. I was hoping there was an easier way than copying the ublas headers to the installation directory, then figuring out the other dependencies by going through headers and tracing #include's. Also, I have gone from just wanting ublas to also wanting the smart pointers. Are they and their dependencies also header-only libraries? When I tried the pointer_test.cpp test program it failed with a seg fault. I compiled the test program by just pointing the compiler at the header files from the tarball. I wanted to be sure I had the library properly installed so I'm back to troubleshooting the installation. David
ublas is a header-only library, but it does have dependencies on other boost libraries. I'm guessing since I've been able to play with ublas a little already the dependencies are also header-only libraries--I definitely don't have any libraries built. I was hoping there was an easier way than copying the ublas headers to the installation directory, then figuring out the other dependencies by going through headers and tracing #include's.
OK, if you just want to copy/install a subset of Boost's headers then use the bcp tool: http://www.boost.org/tools/bcp/bcp.html Obviously you have to use bjam to build it first :-)
Also, I have gone from just wanting ublas to also wanting the smart pointers. Are they and their dependencies also header-only libraries?
Yes.
When I tried the pointer_test.cpp test program it failed with a seg fault. I compiled the test program by just pointing the compiler at the header files from the tarball. I wanted to be sure I had the library properly installed so I'm back to troubleshooting the installation.
Not good: what you did should work, but without knowing more it's impossible to tell what the issue is. Try using bjam to build and run the smart_ptr tests: cd libs/smart_ptr/test bjam -sTOOLS=gcc test According to http://engineering.meta-comm.com/boost-regression/1_33_0/user/smart_ptr.html all the smart_ptr tests should be fine on HP Tru64, but it doesn't look like we have anyone testing on HP-UX though. John.
John Maddock wrote:
ublas is a header-only library, but it does have dependencies on other boost libraries. I'm guessing since I've been able to play with ublas a little already the dependencies are also header-only libraries--I definitely don't have any libraries built. I was hoping there was an easier way than copying the ublas headers to the installation directory, then figuring out the other dependencies by going through headers and tracing #include's.
OK, if you just want to copy/install a subset of Boost's headers then use the bcp tool: http://www.boost.org/tools/bcp/bcp.html
Obviously you have to use bjam to build it first :-)
Actually, it needs more than just bjam. It wants the regex and filesystem libraries as well. There weren't any errors or warnings during compilation, but bcp dies with a bus error when I try running it. I'll take up smart pointers in a separate message. David
John Maddock wrote:
When I tried the pointer_test.cpp test program it failed with a seg fault. I compiled the test program by just pointing the compiler at the header files from the tarball. I wanted to be sure I had the library properly installed so I'm back to troubleshooting the installation.
Not good: what you did should work, but without knowing more it's impossible to tell what the issue is. Try using bjam to build and run the smart_ptr tests:
cd libs/smart_ptr/test bjam -sTOOLS=gcc test
I get 7 failures: smart_ptr_test shared_ptr_basic_test shared_ptr_test weak_ptr_test shared_from_this_test get_deleter_test shared_ptr_alloc_test The following say they've passed: intrusive_ptr_test atomic_count_test lw_mutex_test shared_ptr_assign_fail shared_ptr_delete_fail Tell me which files you're interested in and I can send them along. Below is the output to the terminal from running the tests: ...found 341 targets... ...updating 84 targets... MkDir1 ../../../bin/boost/libs/smart_ptr MkDir1 ../../../bin/boost/libs/smart_ptr/test MkDir1 ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test.o gcc-Link-action ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test Chmod1 ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test execute-test ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test.run /bin/sh[3]: 14355 Memory fault(coredump) ====== BEGIN OUTPUT ====== EXIT STATUS: 139 ====== END OUTPUT ====== ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test > ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test.output 2>&1 status=$? echo >> ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test.output echo EXIT STATUS: $status >> ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test.output if test $status -eq 0 ; then cp -f ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test.output ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test.run fi verbose=1 if test $status -ne 0 ; then verbose=0 fi if test $verbose -eq 0 ; then echo ====== BEGIN OUTPUT ====== cat ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test.output echo ====== END OUTPUT ====== fi exit $status ...failed execute-test ../../../bin/boost/libs/smart_ptr/test/smart_ptr_test.test/gcc/debug/smart_ptr_test.run... MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test.o gcc-Link-action ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test Chmod1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test execute-test ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test.run /bin/sh[3]: 14375 Memory fault(coredump) ====== BEGIN OUTPUT ====== EXIT STATUS: 139 ====== END OUTPUT ====== ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test > ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test.output 2>&1 status=$? echo >> ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test.output echo EXIT STATUS: $status >> ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test.output if test $status -eq 0 ; then cp -f ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test.output ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test.run fi verbose=1 if test $status -ne 0 ; then verbose=0 fi if test $verbose -eq 0 ; then echo ====== BEGIN OUTPUT ====== cat ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test.output echo ====== END OUTPUT ====== fi exit $status ...failed execute-test ../../../bin/boost/libs/smart_ptr/test/shared_ptr_basic_test.test/gcc/debug/shared_ptr_basic_test.run... MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test.o gcc-Link-action ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test Chmod1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test execute-test ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test.run /bin/sh[3]: 14400 Memory fault(coredump) ====== BEGIN OUTPUT ====== EXIT STATUS: 139 ====== END OUTPUT ====== ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test > ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test.output 2>&1 status=$? echo >> ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test.output echo EXIT STATUS: $status >> ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test.output if test $status -eq 0 ; then cp -f ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test.output ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test.run fi verbose=1 if test $status -ne 0 ; then verbose=0 fi if test $verbose -eq 0 ; then echo ====== BEGIN OUTPUT ====== cat ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test.output echo ====== END OUTPUT ====== fi exit $status ...failed execute-test ../../../bin/boost/libs/smart_ptr/test/shared_ptr_test.test/gcc/debug/shared_ptr_test.run... MkDir1 ../../../bin/boost/libs/smart_ptr/test/weak_ptr_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/weak_ptr_test.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/weak_ptr_test.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/weak_ptr_test.test/gcc/debug/weak_ptr_test.o gcc-Link-action ../../../bin/boost/libs/smart_ptr/test/weak_ptr_test.test/gcc/debug/weak_ptr_test Chmod1 ../../../bin/boost/libs/smart_ptr/test/weak_ptr_test.test/gcc/debug/weak_ptr_test execute-test ../../../bin/boost/libs/smart_ptr/test/weak_ptr_test.test/gcc/debug/weak_ptr_test.run /bin/sh[3]: 14420 Memory fault(coredump) ...failed execute-test ../../../bin/boost/libs/smart_ptr/test/weak_ptr_test.test/gcc/debug/weak_ptr_test.run... MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test.o gcc-Link-action ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test Chmod1 ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test execute-test ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test.run /bin/sh[3]: 14439 Memory fault(coredump) ====== BEGIN OUTPUT ====== EXIT STATUS: 139 ====== END OUTPUT ====== ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test > ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test.output 2>&1 status=$? echo >> ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test.output echo EXIT STATUS: $status >> ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test.output if test $status -eq 0 ; then cp -f ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test.output ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test.run fi verbose=1 if test $status -ne 0 ; then verbose=0 fi if test $verbose -eq 0 ; then echo ====== BEGIN OUTPUT ====== cat ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test.output echo ====== END OUTPUT ====== fi exit $status ...failed execute-test ../../../bin/boost/libs/smart_ptr/test/shared_from_this_test.test/gcc/debug/shared_from_this_test.run... MkDir1 ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test.o gcc-Link-action ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test Chmod1 ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test execute-test ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test.run /bin/sh[3]: 14461 Memory fault(coredump) ====== BEGIN OUTPUT ====== EXIT STATUS: 139 ====== END OUTPUT ====== ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test > ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test.output 2>&1 status=$? echo >> ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test.output echo EXIT STATUS: $status >> ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test.output if test $status -eq 0 ; then cp -f ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test.output ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test.run fi verbose=1 if test $status -ne 0 ; then verbose=0 fi if test $verbose -eq 0 ; then echo ====== BEGIN OUTPUT ====== cat ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test.output echo ====== END OUTPUT ====== fi exit $status ...failed execute-test ../../../bin/boost/libs/smart_ptr/test/get_deleter_test.test/gcc/debug/get_deleter_test.run... MkDir1 ../../../bin/boost/libs/smart_ptr/test/intrusive_ptr_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/intrusive_ptr_test.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/intrusive_ptr_test.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/intrusive_ptr_test.test/gcc/debug/intrusive_ptr_test.o gcc-Link-action ../../../bin/boost/libs/smart_ptr/test/intrusive_ptr_test.test/gcc/debug/intrusive_ptr_test Chmod1 ../../../bin/boost/libs/smart_ptr/test/intrusive_ptr_test.test/gcc/debug/intrusive_ptr_test execute-test ../../../bin/boost/libs/smart_ptr/test/intrusive_ptr_test.test/gcc/debug/intrusive_ptr_test.run **passed** ../../../bin/boost/libs/smart_ptr/test/intrusive_ptr_test.test/gcc/debug/intrusive_ptr_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/atomic_count_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/atomic_count_test.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/atomic_count_test.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/atomic_count_test.test/gcc/debug/atomic_count_test.o gcc-Link-action ../../../bin/boost/libs/smart_ptr/test/atomic_count_test.test/gcc/debug/atomic_count_test Chmod1 ../../../bin/boost/libs/smart_ptr/test/atomic_count_test.test/gcc/debug/atomic_count_test execute-test ../../../bin/boost/libs/smart_ptr/test/atomic_count_test.test/gcc/debug/atomic_count_test.run **passed** ../../../bin/boost/libs/smart_ptr/test/atomic_count_test.test/gcc/debug/atomic_count_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/lw_mutex_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/lw_mutex_test.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/lw_mutex_test.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/lw_mutex_test.test/gcc/debug/lw_mutex_test.o gcc-Link-action ../../../bin/boost/libs/smart_ptr/test/lw_mutex_test.test/gcc/debug/lw_mutex_test Chmod1 ../../../bin/boost/libs/smart_ptr/test/lw_mutex_test.test/gcc/debug/lw_mutex_test execute-test ../../../bin/boost/libs/smart_ptr/test/lw_mutex_test.test/gcc/debug/lw_mutex_test.run **passed** ../../../bin/boost/libs/smart_ptr/test/lw_mutex_test.test/gcc/debug/lw_mutex_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_assign_fail.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_assign_fail.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_assign_fail.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/shared_ptr_assign_fail.test/gcc/debug/shared_ptr_assign_fail.o shared_ptr_assign_fail.cpp: In function `int main()': shared_ptr_assign_fail.cpp:30: error: no match for 'operator=' in 'p = (((int*)operator new(4u)), (((*<anonymous>) <unknown operator> 42), <anonymous>))' /disk3/users4/dgarza/boost_1_33_0/boost/shared_ptr.hpp:146: note: candidates are: boost::shared_ptr<T>& boost::shared_ptr<T>::operator=(const boost::shared_ptr<T>&) [with T = int] (failed-as-expected) ../../../bin/boost/libs/smart_ptr/test/shared_ptr_assign_fail.test/gcc/debug/shared_ptr_assign_fail.o **passed** ../../../bin/boost/libs/smart_ptr/test/shared_ptr_assign_fail.test/gcc/debug/shared_ptr_assign_fail.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_delete_fail.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_delete_fail.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_delete_fail.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/shared_ptr_delete_fail.test/gcc/debug/shared_ptr_delete_fail.o shared_ptr_delete_fail.cpp: In function `int main()': shared_ptr_delete_fail.cpp:25: error: type `class boost::shared_ptr<int>' argument given to `delete', expected pointer (failed-as-expected) ../../../bin/boost/libs/smart_ptr/test/shared_ptr_delete_fail.test/gcc/debug/shared_ptr_delete_fail.o **passed** ../../../bin/boost/libs/smart_ptr/test/shared_ptr_delete_fail.test/gcc/debug/shared_ptr_delete_fail.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc MkDir1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug gcc-C++-action ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test.o gcc-Link-action ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test Chmod1 ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test execute-test ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test.run /bin/sh[3]: 14575 Memory fault(coredump) ====== BEGIN OUTPUT ====== EXIT STATUS: 139 ====== END OUTPUT ====== ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test > ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test.output 2>&1 status=$? echo >> ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test.output echo EXIT STATUS: $status >> ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test.output if test $status -eq 0 ; then cp -f ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test.output ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test.run fi verbose=1 if test $status -ne 0 ; then verbose=0 fi if test $verbose -eq 0 ; then echo ====== BEGIN OUTPUT ====== cat ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test.output echo ====== END OUTPUT ====== fi exit $status ...failed execute-test ../../../bin/boost/libs/smart_ptr/test/shared_ptr_alloc_test.test/gcc/debug/shared_ptr_alloc_test.run... ...failed updating 7 targets... ...skipped 7 targets... ...updated 70 targets...
On 11/30/05, David M Garza <David.M.Garza@aero.org> wrote:
John Maddock wrote:
When I tried the pointer_test.cpp test program it failed with a seg fault. I compiled the test program by just pointing the compiler at the header files from the tarball. I wanted to be sure I had the library properly installed so I'm back to troubleshooting the installation.
Not good: what you did should work, but without knowing more it's impossible to tell what the issue is. Try using bjam to build and run the smart_ptr tests:
cd libs/smart_ptr/test bjam -sTOOLS=gcc test
I get 7 failures:
smart_ptr_test shared_ptr_basic_test shared_ptr_test weak_ptr_test shared_from_this_test get_deleter_test shared_ptr_alloc_test
I don't use bjam and haven't ever run the tests in boost, but on HP 11.11 and gcc 3.2.3 we have had extensive troubles with -O2. Plenty of differences from your situation, but it may be worth a try.
I get 7 failures:
smart_ptr_test shared_ptr_basic_test shared_ptr_test weak_ptr_test shared_from_this_test get_deleter_test shared_ptr_alloc_test
Not good, and since bcp replies on shared_ptr that would be why that one failed as well. However I can't reproduce this, on: HP-UX td192 B.11.11 U 9000/800 1839940656 unlimited-user license with Reading specs from /usr/local/lib/gcc/hppa2.0w-hp-hpux11.11/3.4.2/specs Configured with: /scratch/njs/pkgbuild/3.3.1/hpux-11/gcc-3.4.2/configure --enable-languages=c,c++ --enable-threads=posix --disable-nls --with-gnu-as --without-gnu-ld --with-as=/usr/local/bin/as --with-ld=/usr/ccs/bin/ld --with-libiconv-prefix=/usr/local --prefix=/usr/local Thread model: posix gcc version 3.4.2 Where all the smart ptr tests pass OK. I'm cc'ing Peter Dimov as he's our smart_ptr expert. John.
I tried building smart_ptr_test.cpp using the following command: g++ -I /users4/dgarza/boost_1_33_0/ -O0 -o smart_ptr_test smart_ptr_test.cpp just to make sure I had control of the optimization level. When I ran it I got the following output: UDT with value 999888777 being destroyed UDT with value 111222333 being destroyed Segmentation fault (core dumped) When the optimization level goes to -O2, the seg fault turns to a bus error. Again, this is with gcc 3.4.3, and the machine is an Itanium 2 workstation running HPUX 11.22. Building stuff on this machine always ends up turning into such a hassle... If there is any particular test I can run which could help sort out what is going on let me know. I'm afraid I'm a something of a loss on where to go next aside from a platform where testing hs been successful. David John Maddock wrote:
I get 7 failures:
smart_ptr_test shared_ptr_basic_test shared_ptr_test weak_ptr_test shared_from_this_test get_deleter_test shared_ptr_alloc_test
Not good, and since bcp replies on shared_ptr that would be why that one failed as well.
However I can't reproduce this, on:
HP-UX td192 B.11.11 U 9000/800 1839940656 unlimited-user license
with
Reading specs from /usr/local/lib/gcc/hppa2.0w-hp-hpux11.11/3.4.2/specs Configured with: /scratch/njs/pkgbuild/3.3.1/hpux-11/gcc-3.4.2/configure --enable-languages=c,c++ --enable-threads=posix --disable-nls --with-gnu-as --without-gnu-ld --with-as=/usr/local/bin/as --with-ld=/usr/ccs/bin/ld --with-libiconv-prefix=/usr/local --prefix=/usr/local Thread model: posix gcc version 3.4.2
Where all the smart ptr tests pass OK.
I'm cc'ing Peter Dimov as he's our smart_ptr expert.
John.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
David M Garza wrote:
I tried building smart_ptr_test.cpp using the following command:
g++ -I /users4/dgarza/boost_1_33_0/ -O0 -o smart_ptr_test smart_ptr_test.cpp
just to make sure I had control of the optimization level. When I ran it I got the following output:
UDT with value 999888777 being destroyed UDT with value 111222333 being destroyed Segmentation fault (core dumped)
When the optimization level goes to -O2, the seg fault turns to a bus error.
Again, this is with gcc 3.4.3, and the machine is an Itanium 2 workstation running HPUX 11.22.
Itanium? Can you try the same test with -DBOOST_SP_USE_PTHREADS? This could be a problem in the IA64 implementation (boost/detail/sp_counted_base_gcc_ia64.hpp).
Again, this is with gcc 3.4.3, and the machine is an Itanium 2 workstation running HPUX 11.22.
Itanium? Can you try the same test with -DBOOST_SP_USE_PTHREADS? This could be a problem in the IA64 implementation (boost/detail/sp_counted_base_gcc_ia64.hpp).
Reproduced on this HP testdrive machine: td176.testdrive.hp.com And as you suggested -DBOOST_SP_USE_PTHREADS fixes the problem. John.
John Maddock wrote:
Again, this is with gcc 3.4.3, and the machine is an Itanium 2 workstation running HPUX 11.22.
Itanium? Can you try the same test with -DBOOST_SP_USE_PTHREADS? This could be a problem in the IA64 implementation (boost/detail/sp_counted_base_gcc_ia64.hpp).
Reproduced on this HP testdrive machine: td176.testdrive.hp.com
And as you suggested -DBOOST_SP_USE_PTHREADS fixes the problem.
Bad news. We'll probably need to disable the IA64 implementation until an IA64 expert can look into it. Unfortunately 1.33.1 is already out.
David M Garza wrote:
I tried building smart_ptr_test.cpp using the following command:
g++ -I /users4/dgarza/boost_1_33_0/ -O0 -o smart_ptr_test smart_ptr_test.cpp
just to make sure I had control of the optimization level.
This command line is wrong. You must use both the -pthread and -D_REENTRANT options when building multithreaded programs with g++ on IA64. Regrettably Boost.Build did not include -D_REENTRANT in this case prior to version 1.33.1, since it is implied by -pthread on most architectures (so much for portability of GCC!). This error may or may not be responsible for the failures. Ben.
When I added -DBOOST_SP_USE_PTHREADS smart_ptr_test ran, like John Maddock found already. I assume the following output is correct: UDT with value 999888777 being destroyed UDT with value 111222333 being destroyed OK UDT with value 54321 being destroyed UDT with value 333 being destroyed UDT with value 222 being destroyed UDT with value 111 being destroyed UDT with value 333222111 being destroyed No errors detected. For what it's worth, it worked with both -O0 and -O2. Adding "-D_REENTRANT -pthread " to my original g++ command line, on the other hand, did not change the original behavior. Combining Peter's and Ben's suggested flags works. David Ben Hutchings wrote:
David M Garza wrote:
I tried building smart_ptr_test.cpp using the following command:
g++ -I /users4/dgarza/boost_1_33_0/ -O0 -o smart_ptr_test smart_ptr_test.cpp
just to make sure I had control of the optimization level.
This command line is wrong. You must use both the -pthread and -D_REENTRANT options when building multithreaded programs with g++ on IA64. Regrettably Boost.Build did not include -D_REENTRANT in this case prior to version 1.33.1, since it is implied by -pthread on most architectures (so much for portability of GCC!). This error may or may not be responsible for the failures.
Ben.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
David M Garza wrote:
When I added -DBOOST_SP_USE_PTHREADS smart_ptr_test ran, like John Maddock found already. I assume the following output is correct:
UDT with value 999888777 being destroyed UDT with value 111222333 being destroyed OK UDT with value 54321 being destroyed UDT with value 333 being destroyed UDT with value 222 being destroyed UDT with value 111 being destroyed UDT with value 333222111 being destroyed No errors detected.
For what it's worth, it worked with both -O0 and -O2.
Adding "-D_REENTRANT -pthread " to my original g++ command line, on the other hand, did not change the original behavior.
Combining Peter's and Ben's suggested flags works.
If you use -DBOOST_SP_USE_PTHREADS then the IA64-specific code I wrote for manipulating use counts will not be used. This worked on a dual-Itanium system under Linux, but I have not tested it on either the Itanium 2 or HP-UX. (Nor am I easily able to.) If you could use gdb to find exactly where the segmentation fault or bus error occurs, that might help me to track down the bug. You'll need to use the -g option to g++ in order for gdb to produce useful information. Ben.
gdb's stack trace says: #0 0x400f8e1 in boost::detail::atomic_increment (pw=0x40006cc4) at sp_counted_base_gcc_ia64.hpp:38 #1 0x400f890 in boost::detail::sp_counted_base::add_ref_copy (this=0x40006cc0) at sp_counted_base_gcc_ia64.hpp:117 #2 0x400f810 in boost::detail::shared_count::shared_count (this=0x7ffff314, r=@0x7ffff304) at shared_count.hpp:170 #3 0x400fbc0 in boost::shared_ptr<int>::boost::shared_ptr<int> ( this=0x7ffff310, _ctor_arg=@0x7ffff300) at smart_ptr_test.cpp:165 #4 0x400b270:0 in test () at smart_ptr_test.cpp:165 #5 0x400eef0:0 in main () at smart_ptr_test.cpp:308 David Ben Hutchings wrote:
David M Garza wrote:
When I added -DBOOST_SP_USE_PTHREADS smart_ptr_test ran, like John Maddock found already. I assume the following output is correct:
UDT with value 999888777 being destroyed UDT with value 111222333 being destroyed OK UDT with value 54321 being destroyed UDT with value 333 being destroyed UDT with value 222 being destroyed UDT with value 111 being destroyed UDT with value 333222111 being destroyed No errors detected.
For what it's worth, it worked with both -O0 and -O2.
Adding "-D_REENTRANT -pthread " to my original g++ command line, on the other hand, did not change the original behavior.
Combining Peter's and Ben's suggested flags works.
If you use -DBOOST_SP_USE_PTHREADS then the IA64-specific code I wrote for manipulating use counts will not be used. This worked on a dual-Itanium system under Linux, but I have not tested it on either the Itanium 2 or HP-UX. (Nor am I easily able to.) If you could use gdb to find exactly where the segmentation fault or bus error occurs, that might help me to track down the bug. You'll need to use the -g option to g++ in order for gdb to produce useful information.
Ben.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
David M Garza wrote:
gdb's stack trace says:
#0 0x400f8e1 in boost::detail::atomic_increment (pw=0x40006cc4) at sp_counted_base_gcc_ia64.hpp:38
Since gdb is printing the pointers as 32-bit values, and pw is not 64-bit-aligned, it appears that your compiler is using the ILP32 convention (32-bit int, long and pointer types). I assumed the LP64 convention (64-bit long and pointer types, 32-bit int) when writing the assembly-language code in sp_counted_base_gcc_ia64.hpp because I wasn't aware that other conventions were in use on IA64. If the C++ code is compiled with an ILP32 convention then the assembly-language code will be completely broken. I may be able to adjust the code to work to detect the model at compile time and use 32-bit memory accesses if appropriate. Ben.
Ben Hutchings wrote:
David M Garza wrote:
gdb's stack trace says:
#0 0x400f8e1 in boost::detail::atomic_increment (pw=0x40006cc4) at sp_counted_base_gcc_ia64.hpp:38
Since gdb is printing the pointers as 32-bit values, and pw is not 64-bit-aligned, it appears that your compiler is using the ILP32 convention (32-bit int, long and pointer types). I assumed the LP64 convention (64-bit long and pointer types, 32-bit int) when writing the assembly-language code in sp_counted_base_gcc_ia64.hpp because I wasn't aware that other conventions were in use on IA64. If the C++ code is compiled with an ILP32 convention then the assembly-language code will be completely broken. I may be able to adjust the code to work to detect the model at compile time and use 32-bit memory accesses if appropriate.
Another option is to just switch to 'int' and 32-bit accesses (as we did for PPC64 IIRC.)
Peter Dimov wrote:
Ben Hutchings wrote:
David M Garza wrote:
gdb's stack trace says:
#0 0x400f8e1 in boost::detail::atomic_increment (pw=0x40006cc4) at sp_counted_base_gcc_ia64.hpp:38
Since gdb is printing the pointers as 32-bit values, and pw is not 64-bit-aligned, it appears that your compiler is using the ILP32 convention (32-bit int, long and pointer types). I assumed the LP64 convention (64-bit long and pointer types, 32-bit int) when writing the assembly-language code in sp_counted_base_gcc_ia64.hpp because I wasn't aware that other conventions were in use on IA64. If the C++ code is compiled with an ILP32 convention then the assembly-language code will be completely broken. I may be able to adjust the code to work to detect the model at compile time and use 32-bit memory accesses if appropriate.
Another option is to just switch to 'int' and 32-bit accesses (as we did for PPC64 IIRC.)
Yes, that's another possibility, but it breaks binary compatibility - surely a black mark against a bug fix? - and I would expect 32-bit accesses to be a little less efficient. It's fairly easy to select at compile time, in any case. I'm attaching a patch against Boost CVS HEAD that should make it work with both 32-bit and 64-bit longs. Could you test this on HP-UX, David? Ben. Index: boost/detail/sp_counted_base_gcc_ia64.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/sp_counted_base_gcc_ia64.hpp,v retrieving revision 1.2 diff -u -r1.2 sp_counted_base_gcc_ia64.hpp --- boost/detail/sp_counted_base_gcc_ia64.hpp 18 May 2005 20:10:01 -0000 1.2 +++ boost/detail/sp_counted_base_gcc_ia64.hpp 12 Dec 2005 20:00:24 -0000 @@ -16,7 +16,9 @@ // Lock-free algorithm by Alexander Terekhov // +#include <climits> #include <typeinfo> +#include <boost/static_assert.hpp> namespace boost { @@ -24,6 +26,17 @@ namespace detail { +namespace sp_counted_base_conditions +{ +#if LONG_MAX == 2147483647 +BOOST_STATIC_ASSERT(sizeof(long) == 4); +#define BOOST_DETAIL_ASM_LONG "4" +#else +BOOST_STATIC_ASSERT(sizeof(long) == 8); +#define BOOST_DETAIL_ASM_LONG "8" +#endif +} + inline void atomic_increment( long * pw ) { // ++*pw; @@ -33,9 +46,9 @@ // No barrier is required here but fetchadd always has an acquire or // release barrier associated with it. We choose release as it should be // cheaper. - __asm__ ("fetchadd8.rel %0=[%2],1" : - "=r"(tmp), "=m"(*pw) : - "r"(pw)); + __asm__ ("fetchadd"BOOST_DETAIL_ASM_LONG".rel %0=[%2],1" : + "=r"(tmp), "=m"(*pw) : + "r"(pw)); } inline long atomic_decrement( long * pw ) @@ -44,9 +57,9 @@ long rv; - __asm__ (" fetchadd8.rel %0=[%2],-1 ;; \n" - " cmp.eq p7,p0=1,%0 ;; \n" - "(p7) ld8.acq %0=[%2] " : + __asm__ (" fetchadd"BOOST_DETAIL_ASM_LONG".rel %0=[%2],-1 ;; \n" + " cmp.eq p7,p0=1,%0 ;; \n" + "(p7) ld"BOOST_DETAIL_ASM_LONG".acq %0=[%2] " : "=&r"(rv), "=m"(*pw) : "r"(pw) : "p7"); @@ -61,19 +74,19 @@ long rv, tmp, tmp2; - __asm__ ("0: ld8 %0=[%4] ;; \n" - " cmp.eq p7,p0=0,%0 ;; \n" - "(p7) br.cond.spnt 1f \n" - " mov ar.ccv=%0 \n" - " add %1=1,%0 ;; \n" - " cmpxchg8.acq %2=[%4],%1,ar.ccv ;; \n" - " cmp.ne p7,p0=%0,%2 ;; \n" - "(p7) br.cond.spnt 0b \n" - " mov %0=%1 ;; \n" - "1:" : - "=&r"(rv), "=&r"(tmp), "=&r"(tmp2), "=m"(*pw) : - "r"(pw) : - "ar.ccv", "p7"); + __asm__ ("0: ld"BOOST_DETAIL_ASM_LONG" %0=[%4] ;; \n" + " cmp.eq p7,p0=0,%0 ;; \n" + "(p7) br.cond.spnt 1f \n" + " mov ar.ccv=%0 \n" + " add %1=1,%0 ;; \n" + " cmpxchg"BOOST_DETAIL_ASM_LONG".acq %2=[%4],%1,ar.ccv ;; \n" + " cmp.ne p7,p0=%0,%2 ;; \n" + "(p7) br.cond.spnt 0b \n" + " mov %0=%1 ;; \n" + "1:" : + "=&r"(rv), "=&r"(tmp), "=&r"(tmp2), "=m"(*pw) : + "r"(pw) : + "ar.ccv", "p7"); return rv; }
Ben Hutchings wrote:
Peter Dimov wrote:
Another option is to just switch to 'int' and 32-bit accesses (as we did for PPC64 IIRC.)
Yes, that's another possibility, but it breaks binary compatibility - surely a black mark against a bug fix?
Breaking binary compatibility is routine for Boost, even in minor releases.
- and I would expect 32-bit accesses to be a little less efficient.
I doubt that it'd make a difference, except in sizeof(the control block). I think that 32 bits are fine for a reference count, even on a 64 bit platform. :-)
I can test it, but I won't be able to do it until later today. David Ben Hutchings wrote:
Peter Dimov wrote:
Ben Hutchings wrote:
David M Garza wrote:
gdb's stack trace says:
#0 0x400f8e1 in boost::detail::atomic_increment (pw=0x40006cc4) at sp_counted_base_gcc_ia64.hpp:38
Since gdb is printing the pointers as 32-bit values, and pw is not 64-bit-aligned, it appears that your compiler is using the ILP32 convention (32-bit int, long and pointer types). I assumed the LP64 convention (64-bit long and pointer types, 32-bit int) when writing the assembly-language code in sp_counted_base_gcc_ia64.hpp because I wasn't aware that other conventions were in use on IA64. If the C++ code is compiled with an ILP32 convention then the assembly-language code will be completely broken. I may be able to adjust the code to work to detect the model at compile time and use 32-bit memory accesses if appropriate.
Another option is to just switch to 'int' and 32-bit accesses (as we did for PPC64 IIRC.)
Yes, that's another possibility, but it breaks binary compatibility - surely a black mark against a bug fix? - and I would expect 32-bit accesses to be a little less efficient. It's fairly easy to select at compile time, in any case. I'm attaching a patch against Boost CVS HEAD that should make it work with both 32-bit and 64-bit longs. Could you test this on HP-UX, David?
Ben.
------------------------------------------------------------------------
Index: boost/detail/sp_counted_base_gcc_ia64.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/sp_counted_base_gcc_ia64.hpp,v retrieving revision 1.2 diff -u -r1.2 sp_counted_base_gcc_ia64.hpp --- boost/detail/sp_counted_base_gcc_ia64.hpp 18 May 2005 20:10:01 -0000 1.2 +++ boost/detail/sp_counted_base_gcc_ia64.hpp 12 Dec 2005 20:00:24 -0000 @@ -16,7 +16,9 @@ // Lock-free algorithm by Alexander Terekhov //
+#include <climits> #include <typeinfo> +#include <boost/static_assert.hpp>
namespace boost { @@ -24,6 +26,17 @@ namespace detail {
+namespace sp_counted_base_conditions +{ +#if LONG_MAX == 2147483647 +BOOST_STATIC_ASSERT(sizeof(long) == 4); +#define BOOST_DETAIL_ASM_LONG "4" +#else +BOOST_STATIC_ASSERT(sizeof(long) == 8); +#define BOOST_DETAIL_ASM_LONG "8" +#endif +} + inline void atomic_increment( long * pw ) { // ++*pw; @@ -33,9 +46,9 @@ // No barrier is required here but fetchadd always has an acquire or // release barrier associated with it. We choose release as it should be // cheaper. - __asm__ ("fetchadd8.rel %0=[%2],1" : - "=r"(tmp), "=m"(*pw) : - "r"(pw)); + __asm__ ("fetchadd"BOOST_DETAIL_ASM_LONG".rel %0=[%2],1" : + "=r"(tmp), "=m"(*pw) : + "r"(pw)); }
inline long atomic_decrement( long * pw ) @@ -44,9 +57,9 @@
long rv;
- __asm__ (" fetchadd8.rel %0=[%2],-1 ;; \n" - " cmp.eq p7,p0=1,%0 ;; \n" - "(p7) ld8.acq %0=[%2] " : + __asm__ (" fetchadd"BOOST_DETAIL_ASM_LONG".rel %0=[%2],-1 ;; \n" + " cmp.eq p7,p0=1,%0 ;; \n" + "(p7) ld"BOOST_DETAIL_ASM_LONG".acq %0=[%2] " : "=&r"(rv), "=m"(*pw) : "r"(pw) : "p7"); @@ -61,19 +74,19 @@
long rv, tmp, tmp2;
- __asm__ ("0: ld8 %0=[%4] ;; \n" - " cmp.eq p7,p0=0,%0 ;; \n" - "(p7) br.cond.spnt 1f \n" - " mov ar.ccv=%0 \n" - " add %1=1,%0 ;; \n" - " cmpxchg8.acq %2=[%4],%1,ar.ccv ;; \n" - " cmp.ne p7,p0=%0,%2 ;; \n" - "(p7) br.cond.spnt 0b \n" - " mov %0=%1 ;; \n" - "1:" : - "=&r"(rv), "=&r"(tmp), "=&r"(tmp2), "=m"(*pw) : - "r"(pw) : - "ar.ccv", "p7"); + __asm__ ("0: ld"BOOST_DETAIL_ASM_LONG" %0=[%4] ;; \n" + " cmp.eq p7,p0=0,%0 ;; \n" + "(p7) br.cond.spnt 1f \n" + " mov ar.ccv=%0 \n" + " add %1=1,%0 ;; \n" + " cmpxchg"BOOST_DETAIL_ASM_LONG".acq %2=[%4],%1,ar.ccv ;; \n" + " cmp.ne p7,p0=%0,%2 ;; \n" + "(p7) br.cond.spnt 0b \n" + " mov %0=%1 ;; \n" + "1:" : + "=&r"(rv), "=&r"(tmp), "=&r"(tmp2), "=m"(*pw) : + "r"(pw) : + "ar.ccv", "p7");
return rv; }
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
smart_ptr_test still fails. I compiled with g++ -I ../../.. -D_REENTRANT -pthread -g -o smart_ptr_test smart_ptr_test.cpp The gdb output is (gdb) run Starting program: /disk3/users4/dgarza/boost_test/boost_cvs/boost/libs/smart_ptr/test/smart_ptr_test UDT with value 999888777 being destroyed UDT with value 111222333 being destroyed Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x400f881 in boost::detail::atomic_increment (pw=0x40006cc4) at sp_counted_base_gcc_ia64.hpp:51 warning: Compilation directory is not absolute; could result in incorrect behavior. Please report to HP. 51 "r"(pw)); (gdb) where #0 0x400f881 in boost::detail::atomic_increment (pw=0x40006cc4) at sp_counted_base_gcc_ia64.hpp:51 #1 0x400f830 in boost::detail::sp_counted_base::add_ref_copy (this=0x40006cc0) at sp_counted_base_gcc_ia64.hpp:130 #2 0x400f7b0 in boost::detail::shared_count::shared_count (this=0x7ffff2e4, r=@0x7ffff2d4) at shared_count.hpp:216 #3 0x400fb60 in boost::shared_ptr<int>::boost::shared_ptr<int> ( this=0x7ffff2e0, _ctor_arg=@0x7ffff2d0) at smart_ptr_test.cpp:165 #4 0x400b210:0 in test () at smart_ptr_test.cpp:165 #5 0x400ee90:0 in main () at smart_ptr_test.cpp:308 I grabbed the CVS instead of using the 1.33.0 package I was working with before. I assume this was what you intended? As an aside, do I gather correctly from the presence of "-D_REENTRANT -pthread" the smart pointer code is multithreaded? Anything I write using smart pointers, regardless of whether or not my code is multithreaded, will require the flags? David
David M Garza wrote:
smart_ptr_test still fails. I compiled with
g++ -I ../../.. -D_REENTRANT -pthread -g -o smart_ptr_test smart_ptr_test.cpp
The gdb output is
(gdb) run Starting program: /disk3/users4/dgarza/boost_test/boost_cvs/boost/libs/smart_ptr/test/smart_ptr_test
UDT with value 999888777 being destroyed UDT with value 111222333 being destroyed
Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x400f881 in boost::detail::atomic_increment (pw=0x40006cc4) at sp_counted_base_gcc_ia64.hpp:51 warning: Compilation directory is not absolute; could result in incorrect behavior. Please report to HP. 51 "r"(pw)); (gdb) where #0 0x400f881 in boost::detail::atomic_increment (pw=0x40006cc4) at sp_counted_base_gcc_ia64.hpp:51 #1 0x400f830 in boost::detail::sp_counted_base::add_ref_copy (this=0x40006cc0) at sp_counted_base_gcc_ia64.hpp:130 #2 0x400f7b0 in boost::detail::shared_count::shared_count (this=0x7ffff2e4, r=@0x7ffff2d4) at shared_count.hpp:216 #3 0x400fb60 in boost::shared_ptr<int>::boost::shared_ptr<int> ( this=0x7ffff2e0, _ctor_arg=@0x7ffff2d0) at smart_ptr_test.cpp:165 #4 0x400b210:0 in test () at smart_ptr_test.cpp:165 #5 0x400ee90:0 in main () at smart_ptr_test.cpp:308
I grabbed the CVS instead of using the 1.33.0 package I was working with before. I assume this was what you intended?
Did you also apply the patch I attached? I won't commit that change to CVS unless and until you confirm that it works in an ILP32 configuration.
As an aside, do I gather correctly from the presence of "-D_REENTRANT -pthread" the smart pointer code is multithreaded?
It's intended to be thread-safe if necessary. The purpose of the assembly-language code is to do reference-counting in a thread-safe and efficient way (use of mutexes for reference-counting is quite expensive).
Anything I write using smart pointers, regardless of whether or not my code is multithreaded, will require the flags?
If BOOST_DISABLE_THREADS is defined then you will get a non-thread-safe and more efficient version of sp_counted_base. You must ensure that all translation units that use sp_counted_base get a consistent definition (the One Definition Rule). So you should choose either "-D_REENTRANT -pthread" or "-DBOOST_DISABLE_THREADS" and use it consistently. Ben.
Ben Hutchings wrote: ...
I grabbed the CVS instead of using the 1.33.0 package I was working with before. I assume this was what you intended?
Did you also apply the patch I attached? I won't commit that change to CVS unless and until you confirm that it works in an ILP32 configuration.
This was with the patch already applied. I wasn't very specific in what I wrote--I meant I applied the patch to what I got from CVS as opposed to applying it to 1.33.0. Sorry.
As an aside, do I gather correctly from the presence of "-D_REENTRANT -pthread" the smart pointer code is multithreaded?
It's intended to be thread-safe if necessary. The purpose of the assembly-language code is to do reference-counting in a thread-safe and efficient way (use of mutexes for reference-counting is quite expensive).
Anything I write using smart pointers, regardless of whether or not my code is multithreaded, will require the flags?
If BOOST_DISABLE_THREADS is defined then you will get a non-thread-safe and more efficient version of sp_counted_base. You must ensure that all translation units that use sp_counted_base get a consistent definition (the One Definition Rule). So you should choose either "-D_REENTRANT -pthread" or "-DBOOST_DISABLE_THREADS" and use it consistently.
Okay. I'm thinking right now I'll end up using BOOST_DISABLE_THREADS since I don't intend to spawn multiple threads myself--my project is a serial numerical analysis code. Once I was doing a project involving Java and I read a Java programer still had to consider thread safety regardless of whether or not the program code explicitly spawned multiple threads because, while the program's code might not explicitly spawn many threads, Java class library methods could spawn multiple threads when called. I think this came up in particular when I was doing Java-C++-Fortran cross-language programming. David
Yes, that's another possibility, but it breaks binary compatibility - surely a black mark against a bug fix? - and I would expect 32-bit accesses to be a little less efficient. It's fairly easy to select at compile time, in any case. I'm attaching a patch against Boost CVS HEAD that should make it work with both 32-bit and 64-bit longs. Could you test this on HP-UX, David?
You are right that int's and pointers are 32-bit: sizeof(short) =2 sizeof(int) =4 sizeof(long) =4 sizeof(size_t) =4 sizeof(ptrdiff_t) =4 sizeof(void*) =4 sizeof(void(*)(void)) =4 sizeof(float) =4 sizeof(double) =8 sizeof(long double) =16 CHAR_BIT =8 CHAR_MAX =127 SHRT_MAX =32767 INT_MAX =2147483647 LONG_MAX =2147483647L LONG_LONG_MAX =9223372036854775807LL ULONG_LONG_MAX =(9223372036854775807LL * 2ULL + ULL) But your fix still segfaults: bash-2.05b$ gdb *test HP gdb 5.2 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 5.2 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. .. (gdb) run Starting program: /house/maddock/bin/boost/libs/smart_ptr/test/smart_ptr_test.te st/gcc/debug/smart_ptr_test UDT with value 999888777 being destroyed UDT with value 111222333 being destroyed Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x400f041 in boost::detail::atomic_increment (pw=0x40012b94) at sp_counted_base_gcc_ia64.hpp:51 51 "r"(pw)); (gdb) bt #0 0x400f041 in boost::detail::atomic_increment (pw=0x40012b94) at sp_counted_base_gcc_ia64.hpp:51 #1 0x400f500 in boost::detail::sp_counted_base::add_ref_copy (this=0x40012b90) at sp_counted_base_gcc_ia64.hpp:130 #2 0x400f970 in boost::detail::shared_count::shared_count (this=0x7ffff30c, r=@0x7ffff304) at shared_count.hpp:216 #3 0x4010d70 in boost::shared_ptr<int>::boost::shared_ptr<int> ( this=0x7ffff308) at shared_ptr.hpp:116 #4 0x400ad40:0 in test () at smart_ptr_test.cpp:165 #5 0x400ec50:0 in main () at smart_ptr_test.cpp:308 John.
If you use -DBOOST_SP_USE_PTHREADS then the IA64-specific code I wrote for manipulating use counts will not be used. This worked on a dual-Itanium system under Linux, but I have not tested it on either the Itanium 2 or HP-UX. (Nor am I easily able to.) If you could use gdb to find exactly where the segmentation fault or bus error occurs, that might help me to track down the bug. You'll need to use the -g option to g++ in order for gdb to produce useful information.
Some more information: the problem does *not* occur on Red Hat Linux/IA64 or FreeBSD/IA64. The HP-UX problem you can reproduce/test for yourself by signing up for a HP-testdrive account and logging on to td176.testdrive.hp.com (see http://www.testdrive.hp.com/current.shtml). But you'll see: td176> g++ -I../../../ -g smart*.cpp td176> gdb a.out HP gdb 5.2 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 5.2 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. .. (gdb) run Starting program: /house/maddock/libs/smart_ptr/test/a.out UDT with value 999888777 being destroyed UDT with value 111222333 being destroyed Program received signal SIGSEGV, Segmentation fault si_code: 1 - SEGV_MAPERR - Address not mapped to object. 0x400f021 in boost::detail::atomic_increment (pw=0x40012b94) at sp_counted_base_gcc_ia64.hpp:38 warning: Compilation directory is not absolute; could result in incorrect behavi or. Please report to HP. 38 "r"(pw)); (gdb) bt #0 0x400f021 in boost::detail::atomic_increment (pw=0x40012b94) at sp_counted_base_gcc_ia64.hpp:38 #1 0x400f4e0 in boost::detail::sp_counted_base::add_ref_copy (this=0x40012b90) at sp_counted_base_gcc_ia64.hpp:117 #2 0x400f950 in boost::detail::shared_count::shared_count (this=0x7ffff44c, r=@0x7ffff444) at shared_count.hpp:216 #3 0x4010d50 in boost::shared_ptr<int>::boost::shared_ptr<int> ( this=0x7ffff448) at shared_ptr.hpp:116 #4 0x400ad20:0 in test () at smart_ptr_test.cpp:165 #5 0x400ec30:0 in main () at smart_ptr_test.cpp:308 HTH, John.
David M Garza wrote:
ublas is a header-only library, but it does have dependencies on other boost libraries. I'm guessing since I've been able to play with ublas a little already the dependencies are also header-only libraries--I definitely don't have any libraries built. I was hoping there was an easier way than copying the ublas headers to the installation directory, then figuring out the other dependencies by going through headers and tracing #include's.
Look at $(BOOST_ROOT)/tools/bcp ... to copy those bits of boost you need.... easier than manual searching at least. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
participants (1)
-
Ben Hutchings -
David M Garza -
John Maddock -
Kevin Wheatley -
Peter Dimov -
Thomas Matelich