Problems building Boost 1.27.0 libraries
I have downloaded Boost and am trying to build the libraries on Solaris 8 with g++ 2.95.3: jam -sBOOST_ROOT=. -sTOOLS=gcc -sBUILD="debug release" The thread library has an error building once.cpp: gcc-C++-action libs/thread/build/bin/libboost_thread/gcc/release/runtime-link-dy namic/threading-multi/once.o g++: unrecognized option `-pthread' libs/thread/build/../src/once.cpp:42: warning: aggregate has a partly bracketed initializer libs/thread/build/../src/once.cpp:138: parse error at end of input g++ -c -Wall -ftemplate-depth-100 -DNDEBUG -O4 -finline-functions -Wno-in line -pthread -I"libs/thread/build" -I"." -o "libs/thread/build/bin/libboost _thread/gcc/release/runtime-link-dynamic/threading-multi/once.o" "libs/thread/b uild/../src/once.cpp" ...failed gcc-C++-action libs/thread/build/bin/libboost_thread/gcc/release/runti me-link-dynamic/threading-multi/once.o ... The Python library seems to have some missing files. Lots of errors of this type: -- In file included from boost/python/detail/base_object.hpp:16, from boost/python/detail/types.hpp:27, from boost/python/detail/call_object.hpp:9, from libs/python/build/../src/types.cpp:11: boost/python/detail/wrap_python.hpp:24: patchlevel.h: No such file or directory boost/python/detail/wrap_python.hpp:100: Python.h: No such file or directory The regex library builds fine, but I get the following errors when I use the gcc.mak makefile to build and run the regression test in libs/regex/test/regress: g++ -pedantic -Wall -I../../../../ -I./ -L../../build/gcc -O2 -o r2 tests.cpp parse.cpp regress.cpp -lboost_regex In file included from ../../../../boost/regex/config.hpp:51, from ../../../../boost/cregex.hpp:27, from ../../../../boost/regex.hpp:31, from tests.cpp:26: ../../../../boost/cstdint.hpp:202: too many `l's in integer constant ../../../../boost/cstdint.hpp:205: #error defaults not correct; you must hand mo dify boost/cstdint.hpp In file included from ../../../../boost/regex/config.hpp:51, from ../../../../boost/cregex.hpp:27, from ../../../../boost/regex.hpp:31, from parse.cpp:25: ../../../../boost/cstdint.hpp:202: too many `l's in integer constant ../../../../boost/cstdint.hpp:205: #error defaults not correct; you must hand mo dify boost/cstdint.hpp In file included from ../../../../boost/regex/config.hpp:51, from ../../../../boost/cregex.hpp:27, from ../../../../boost/regex.hpp:31, from regress.cpp:26: ../../../../boost/cstdint.hpp:202: too many `l's in integer constant ../../../../boost/cstdint.hpp:205: #error defaults not correct; you must hand mo dify boost/cstdint.hpp make: *** [r2] Error 1 I can work around this one by modifying gcc.mak to remove the -pedantic option. I would appreciate any help I can get with the other errors. Are the Python and Threads libraries not supported with my configuration? Thanks, -- Paul M. Dubuc
That's a bug that's been partly fixed in the latest cvs source - the -pthread flag should be -pthreads. However that's not the end of it, because the std lib that ships with gcc on solaris has a problem with std::runtime_error when you build with -pthreads (basically the code doesn't link because the body of runtime_error::runtime_error is missing in the headers), I don't know what the solution to this is, other than to fix your std lib (or maybe use STLPort). John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm
I have downloaded Boost and am trying to build the libraries on Solaris 8 with g++ 2.95.3:
jam -sBOOST_ROOT=. -sTOOLS=gcc -sBUILD="debug release"
The thread library has an error building once.cpp:
gcc-C++-action libs/thread/build/bin/libboost_thread/gcc/release/runtime-link-dy namic/threading-multi/once.o g++: unrecognized option `-pthread' libs/thread/build/../src/once.cpp:42: warning: aggregate has a partly bracketed initializer libs/thread/build/../src/once.cpp:138: parse error at end of input
g++ -c -Wall -ftemplate-depth-100 -DNDEBUG -O4 -finline-functions -Wno-in line -pthread -I"libs/thread/build" -I"." -o "libs/thread/build/bin/libboost _thread/gcc/release/runtime-link-dynamic/threading-multi/once.o" "libs/thread/b uild/../src/once.cpp"
...failed gcc-C++-action libs/thread/build/bin/libboost_thread/gcc/release/runti me-link-dynamic/threading-multi/once.o ...
The Python library seems to have some missing files. Lots of errors of this type:
-- In file included from boost/python/detail/base_object.hpp:16, from boost/python/detail/types.hpp:27, from boost/python/detail/call_object.hpp:9, from libs/python/build/../src/types.cpp:11: boost/python/detail/wrap_python.hpp:24: patchlevel.h: No such file or directory boost/python/detail/wrap_python.hpp:100: Python.h: No such file or directory
The regex library builds fine, but I get the following errors when I use the gcc.mak makefile to build and run the regression test in libs/regex/test/regress:
g++ -pedantic -Wall -I../../../../ -I./ -L../../build/gcc -O2 -o r2 tests.cpp parse.cpp regress.cpp -lboost_regex In file included from ../../../../boost/regex/config.hpp:51, from ../../../../boost/cregex.hpp:27, from ../../../../boost/regex.hpp:31, from tests.cpp:26: ../../../../boost/cstdint.hpp:202: too many `l's in integer constant ../../../../boost/cstdint.hpp:205: #error defaults not correct; you must hand mo dify boost/cstdint.hpp In file included from ../../../../boost/regex/config.hpp:51, from ../../../../boost/cregex.hpp:27, from ../../../../boost/regex.hpp:31, from parse.cpp:25: ../../../../boost/cstdint.hpp:202: too many `l's in integer constant ../../../../boost/cstdint.hpp:205: #error defaults not correct; you must hand mo dify boost/cstdint.hpp In file included from ../../../../boost/regex/config.hpp:51, from ../../../../boost/cregex.hpp:27, from ../../../../boost/regex.hpp:31, from regress.cpp:26: ../../../../boost/cstdint.hpp:202: too many `l's in integer constant ../../../../boost/cstdint.hpp:205: #error defaults not correct; you must hand mo dify boost/cstdint.hpp make: *** [r2] Error 1
I can work around this one by modifying gcc.mak to remove the -pedantic option.
I would appreciate any help I can get with the other errors. Are the Python and Threads libraries not supported with my configuration? Thanks,
-- Paul M. Dubuc
Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
That's a bug that's been partly fixed in the latest cvs source - the -pthread flag should be -pthreads.
However that's not the end of it, because the std lib that ships with gcc on solaris has a problem with std::runtime_error when you build with -pthreads (basically the code doesn't link because the body of runtime_error::runtime_error is missing in the headers), I don't know what the solution to this is, other than to fix your std lib (or maybe use STLPort).
I have downloaded Boost and am trying to build the libraries on
Solaris
8 with g++ 2.95.3:
I ran into this problem just recently. I think John's diagnosis is incorrect. In fact, stdexcept includes the body of runtime_error just fine, and the class runtime_error exists. Part of the problem is that the gcc standard library, when compiled under -pthreads, typedefs std::string (and all the other default std::containers) differently from how it is defined under single-threaded compilation. The default allocator is defined to be: typedef __default_alloc_template<__NODE_ALLOCATOR_THREADS, 0> alloc; where __NODE_ALLOCATOR_THREADS is a #define which is true if threading is enabled, false otherwise. This in itself is still not the real problem. The problem is that the constructor of runtime_error, and all the other stdexcept classes, is not actually compiled under pthreads, because stdexcept has a #pragma interface "stdexcept" line in it which inhibits the compiler from emitting the bodies of these inline functions. Which it also does in non-threaded compiling mode, but in that mode the gcc writers have conveniently put the non-threaded definitions into the libstdc++, so your link works fine. I think there is a workaround: put #pragma implementation "stdexcept" in one of of your source files which includes <stdexcept>. This will cause those bodies to be emitted and your link should go fine. I haven't tested it myself for various local technical reasons, but I think it will work. Good luck, and let me know if it works! If it does, we should maybe propose that the boost Threads library include such definitions under gcc. George Heintzelman georgeh@aya.yale.edu
participants (3)
-
George A. Heintzelman -
John Maddock -
Paul Dubuc