Hi, I've been trying to compile Boost on OpenBSD 3.8 with no success, but I would like to have the threading library available. I've gone through the list a few times, and the only thing related to OpenBSD was posted back in '02 or '03. I compiled GCC 3.4.4 with threads because the default compiler is not threaded and run ./configure as the docs say, but I still can't get it to work. Is there anything else I need to know to get Boost::Threads to compile properly? Thanks
I've been trying to compile Boost on OpenBSD 3.8 with no success, but I would like to have the threading library available. I've gone through the list a few times, and the only thing related to OpenBSD was posted back in '02 or '03.
I compiled GCC 3.4.4 with threads because the default compiler is not threaded and run ./configure as the docs say, but I still can't get it to work.
We'll need to know what errors you're seeing before anyone can help. John.
John Maddock wrote:
I've been trying to compile Boost on OpenBSD 3.8 with no success, but I would like to have the threading library available. I've gone through the list a few times, and the only thing related to OpenBSD was posted back in '02 or '03.
I compiled GCC 3.4.4 with threads because the default compiler is not threaded and run ./configure as the docs say, but I still can't get it to work.
We'll need to know what errors you're seeing before anyone can help.
John. This gets repeated several times: gcc-C++-action bin/boost/libs/thread/build/libboost_thread.so/gcc/debug/shared-linkable-true/threading-multi/barrier.o In file included from /home/quantum/boost_1_33_1/boost/thread/detail/config.hpp:18, from /home/quantum/boost_1_33_1/libs/thread/src/barrier.cpp:12: /home/quantum/boost_1_33_1/boost/config/requires_threads.hpp:29:4: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS"
GCC is configured like this: -bash-3.00# i386-unknown-openbsd3.8-egcc -v Reading specs from /usr/local/lib/gcc/i386-unknown-openbsd3.8/3.4.4/specs Configured with: /usr/ports/lang/gcc/3.4/w-gcc-3.4-20050401p0/gcc-3.4-20050401/configure --verbose --program-transform-name=s,^,e, --disable-nls --with-system-zlib --enable-languages=c,c++,f77,objc,java --enable-cpp --enable-sjlj-exceptions --enable-threads=posix --with-gnu-as --with-gnu-ld --enable-shared --prefix=/usr/local --sysconfdir=/etc Thread model: posix gcc version 3.4.4 20050401 (prerelease) I have the option of trying GCC 4.0 and 4.1, but GCC 3.3 failed to compile with Posix threads turned on. I tried using the configure script and then running make to execute the makefile - shouldn't the configure script have detected threading availability in the compiler? Thanks
This gets repeated several times: gcc-C++-action bin/boost/libs/thread/build/libboost_thread.so/gcc/debug/shared-linkable-true/threading-multi/barrier.o In file included from /home/quantum/boost_1_33_1/boost/thread/detail/config.hpp:18, from /home/quantum/boost_1_33_1/libs/thread/src/barrier.cpp:12: /home/quantum/boost_1_33_1/boost/config/requires_threads.hpp:29:4: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS"
I tried using the configure script and then running make to execute the makefile - shouldn't the configure script have detected threading availability in the compiler?
It's turning off threading support because it thinks your libstdc++ is built single threaded: however I have a suspicion this is may be due to a bug I fixed a while back - basically it means that if you configure gcc with --enable-threads=posix rather than --enable-threads=default then our config doesn't correctly detect that case (in case you're thinking "but they're the same thing!", they're not at least as far as the macros set by libstdc++ are concerned). Anyway can you try replacing boost/config/stdlib/libstdcpp3.hpp with the current cvs version (attached) and see if that fixes things? John.
John Maddock wrote:
This gets repeated several times: gcc-C++-action bin/boost/libs/thread/build/libboost_thread.so/gcc/debug/shared-linkable-true/threading-multi/barrier.o
In file included from /home/quantum/boost_1_33_1/boost/thread/detail/config.hpp:18, from /home/quantum/boost_1_33_1/libs/thread/src/barrier.cpp:12: /home/quantum/boost_1_33_1/boost/config/requires_threads.hpp:29:4: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS"
I tried using the configure script and then running make to execute the makefile - shouldn't the configure script have detected threading availability in the compiler?
It's turning off threading support because it thinks your libstdc++ is built single threaded: however I have a suspicion this is may be due to a bug I fixed a while back - basically it means that if you configure gcc with --enable-threads=posix rather than --enable-threads=default then our config doesn't correctly detect that case (in case you're thinking "but they're the same thing!", they're not at least as far as the macros set by libstdc++ are concerned).
Anyway can you try replacing boost/config/stdlib/libstdcpp3.hpp with the current cvs version (attached) and see if that fixes things?
[snip attachment] Hi, I tried your suggestion and got this error message: ...failed gcc-C++-action bin/boost/libs/thread/build/libboost_thread.a/gcc/release/threading-multi/tss.o... gcc-C++-action bin/boost/libs/thread/build/libboost_thread.a/gcc/release/threading-multi/xtime.o In file included from /home/quantum/boost_1_33_1/boost/thread/detail/config.hpp:18, from /home/quantum/boost_1_33_1/libs/thread/src/xtime.cpp:12: /home/quantum/boost_1_33_1/boost/config/requires_threads.hpp:47:5: #error "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)" set -e "g++" -c -Wall -ftemplate-depth-255 -DNDEBUG -DNDEBUG -DBOOST_THREAD_LIB_NAME=boost_thread -DBOOST_THREAD_BUILD_LIB=1 -O3 -finline-functions -Wno-inline -pthread -I"bin/boost/libs/thread/build" -I "/home/quantum/boost_1_33_1" -o "bin/boost/libs/thread/build/libboost_thread.a/gcc/release/threading-multi/xtime.o" "/home/quantum/boost_1_33_1/libs/thread/build/../src/xtime.cpp" Any other suggestions? I've already set the LIBS variable to "-lpthread".
I tried your suggestion and got this error message:
Any other suggestions? I've already set the LIBS variable to "-lpthread".
OK we're making progress (honestly!) can you please try one more patch this time to boost/platform/bsd.hpp, basically I suspect the unistd.h isn't defining _POSIX_THREADS so threading support isn't picked up on. John.
John Maddock wrote:
I tried your suggestion and got this error message:
Any other suggestions? I've already set the LIBS variable to "-lpthread".
OK we're making progress (honestly!) can you please try one more patch this time to boost/platform/bsd.hpp, basically I suspect the unistd.h isn't defining _POSIX_THREADS so threading support isn't picked up on.
John. // (C) Copyright John Maddock 2001 - 2003. // (C) Copyright Darin Adler 2001. // (C) Copyright Douglas Gregor 2002. // Use, modification and distribution are subject to the // Boost Software License, Version 1.0. (See accompanying file // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
I can't find a boost/platform/bsd.hpp, but there is a boost/config/platform/bsd.hpp which I replaced and got the same error message. Out of curiosity, is Boost not regularly tested with OpenBSD? If not, I'd like to submit these experiences for documentation on working with OpenBSD and Boost. Thanks again.
I can't find a boost/platform/bsd.hpp, but there is a boost/config/platform/bsd.hpp which I replaced and got the same error message.
Darn, OK one last try to find the cause of the problem, can you please try building the short program below with g++ -pthread ...etc and let me know which #errors get triggered?
Out of curiosity, is Boost not regularly tested with OpenBSD? If not, I'd like to submit these experiences for documentation on working with OpenBSD and Boost.
No we don't have a regular OpenBSD regression test runner, volunteers are
always welcome of course :-)
John.
And the program:
#include
John Maddock wrote:
I can't find a boost/platform/bsd.hpp, but there is a boost/config/platform/bsd.hpp which I replaced and got the same error message.
Darn, OK one last try to find the cause of the problem, can you please try building the short program below with g++ -pthread ...etc and let me know which #errors get triggered?
Out of curiosity, is Boost not regularly tested with OpenBSD? If not, I'd like to submit these experiences for documentation on working with OpenBSD and Boost.
No we don't have a regular OpenBSD regression test runner, volunteers are always welcome of course :-)
John.
And the program:
#include
#ifndef BOOST_HAS_THREADS #error err1 #endif #include #ifndef BOOST_HAS_THREADS #error err2 #endif #include #ifndef BOOST_HAS_THREADS #error err3 #endif #ifndef BOOST_HAS_PTHREADS #error err4 #endif #include #ifndef BOOST_HAS_THREADS #error err5 #endif #ifndef BOOST_HAS_PTHREADS #error err6 #endif
Hi John, You weren't explicit on where to get the headers from, so I tried it once from /usr/local/include, and once from within the build directory. I added a 'int main( void ){ return 0; }' once I realized that it compiled fine with local headers. -bash-3.00# i386-unknown-openbsd3.8-eg++ -I/usr/local/include/boost-1_33_1 tryme .c tryme.c:14:2: #error err4 tryme.c:18:2: #error err5 tryme.c:21:2: #error err6 -bash-3.00# i386-unknown-openbsd3.8-eg++ -I/home/quantum/boost_1_33_1 tryme.c -bash-3.00# i386-unknown-openbsd3.8-eg++ -o tryme tryme.o tryme.o(.init+0x0): In function `__init': : multiple definition of `__init' /usr/lib/crtbegin.o(.init+0x0): first defined here tryme.o(.text+0x0): In function `_start': : multiple definition of `__start' /usr/lib/crt0.o(.text+0x0): first defined here tryme.o(.data+0x0): multiple definition of `__progname' /usr/lib/crt0.o(.data+0x0): first defined here tryme.o(.text+0x0): In function `_start': : multiple definition of `_start' /usr/lib/crt0.o(.text+0x0): first defined here tryme.o(.fini+0x0): In function `__fini': : multiple definition of `__fini' /usr/lib/crtbegin.o(.fini+0x0): first defined here tryme.o(.text+0x18): In function `___start': : multiple definition of `___start' /usr/lib/crt0.o(.text+0x18): first defined here /usr/lib/crt0.o(.dynamic+0x0): multiple definition of `_DYNAMIC' /usr/lib/crt0.o(.got.plt+0x0): multiple definition of `_GLOBAL_OFFSET_TABLE_' collect2: ld returned 1 exit status Thanks
-bash-3.00# i386-unknown-openbsd3.8-eg++ -I/usr/local/include/boost-1_33_1 tryme .c tryme.c:14:2: #error err4 tryme.c:18:2: #error err5 tryme.c:21:2: #error err6
That's what I would have expected to see *without* the patched bsd.hpp I sent you, so the question is, why isn't: #if (defined(__FreeBSD__) && (__FreeBSD__ <= 3)) || defined(__OpenBSD__) # define BOOST_HAS_PTHREADS #endif In the modified bsd.hpp getting triggered and defining BOOST_HAS_PTHREADS ? __OpenBSD__ is the correct define to check for OpenBSD isn't it? Or was the patch not correctly applied maybe? John.
John Maddock wrote:
I can't find a boost/platform/bsd.hpp, but there is a boost/config/platform/bsd.hpp which I replaced and got the same error message.
Darn, OK one last try to find the cause of the problem, can you please try building the short program below with g++ -pthread ...etc and let me know which #errors get triggered?
Out of curiosity, is Boost not regularly tested with OpenBSD? If not, I'd like to submit these experiences for documentation on working with OpenBSD and Boost.
No we don't have a regular OpenBSD regression test runner, volunteers are always welcome of course :-)
John.
And the program:
#include
#ifndef BOOST_HAS_THREADS #error err1 #endif #include #ifndef BOOST_HAS_THREADS #error err2 #endif #include #ifndef BOOST_HAS_THREADS #error err3 #endif #ifndef BOOST_HAS_PTHREADS #error err4 #endif #include #ifndef BOOST_HAS_THREADS #error err5 #endif #ifndef BOOST_HAS_PTHREADS #error err6 #endif
Wait...I forgot the -pthread when compiling it...it works both times.
John Maddock wrote:
Wait...I forgot the -pthread when compiling it...it works both times.
What do you mean by "works" ? same error messages? or clean compile?
John. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Clean compile. As for applying the patch, I simply replaced the headers in question with the ones you gave me. I don't know what I'm doing wrong. I'll unpack the sources, reapply the patches and try again.
I've tried reapplying both patches...and have got clean compiles.
Thanks for your help so far.
On 2/14/06, Todd Jackson
John Maddock wrote:
Wait...I forgot the -pthread when compiling it...it works both times.
What do you mean by "works" ? same error messages? or clean compile?
John. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Clean compile.
As for applying the patch, I simply replaced the headers in question with the ones you gave me. I don't know what I'm doing wrong.
I'll unpack the sources, reapply the patches and try again.
-- Todd Jackson http://quantumskyline.homelinux.net/wordpress
I guess I'm screwed then, eh? :)
Is it possible to get Boost.Jam or the compile process to dump which version
of GCC its using on my system? While I've explicitly set the name of the
compiler, I'm getting the impression that the configure script is picking up
the original compiler shipped with OpenBSD (GCC 3.3.4, single threaded)
instead of my 'custom' compiler (GCC 3.4.4, Posix threads).
Thanks
On 2/14/06, John Maddock
Clean compile.
If you get a clean compile with no #errors, then Boost.Thread should build.
John.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Todd Jackson http://quantumskyline.homelinux.net/wordpress
Quantum Skyline wrote:
I guess I'm screwed then, eh? :)
Is it possible to get Boost.Jam or the compile process to dump which version of GCC its using on my system?
If you execute bjam directly, instead of from the Makefile, you can pass it a "-d+2" option which prints out all the commands it executes. And yes, running it through the Makefile is likely using the default system compiler. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
-bash-3.00# ./bjam -sTOOLS=gcc --without-python --with-thread "-d+2"
...
set -e
"g++" -c -Wall -ftemplate-depth-255 -DNDEBUG -DNDEBUG
-DBOOST_THREAD_LIB_NAME=boost_thread -DBOOST_THREAD_BUILD_DLL=1 -O3
-finline-functions -Wno-inline -pthread -fPIC
-I"bin/boost/libs/thread/build" -I "/home/quantum/boost_1_33_1" -o
"bin/boost/libs/thread/build/libboost_thread.so/gcc/release/shared-linkable-true/threading-multi/exceptions.o"
"/home/quantum/boost_1_33_1/libs/thread/build/../src/exceptions.cpp"
I've only snipped the error messages, but g++ is not my compiler. I've set
CXX=i386-unknown-openbsd3.8-eg++, 'cause that's what its named on OpenBSD
when you build a compiler from ports.
On 2/14/06, Rene Rivera
Quantum Skyline wrote:
I guess I'm screwed then, eh? :)
Is it possible to get Boost.Jam or the compile process to dump which version of GCC its using on my system?
If you execute bjam directly, instead of from the Makefile, you can pass it a "-d+2" option which prints out all the commands it executes. And yes, running it through the Makefile is likely using the default system compiler.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Todd Jackson http://quantumskyline.homelinux.net/wordpress
Quantum Skyline wrote:
-bash-3.00# ./bjam -sTOOLS=gcc --without-python --with-thread "-d+2" ... set -e "g++" -c -Wall -ftemplate-depth-255 -DNDEBUG -DNDEBUG -DBOOST_THREAD_LIB_NAME=boost_thread -DBOOST_THREAD_BUILD_DLL=1 -O3 -finline-functions -Wno-inline -pthread -fPIC -I"bin/boost/libs/thread/build" -I "/home/quantum/boost_1_33_1" -o "bin/boost/libs/thread/build/libboost_thread.so/gcc/release/shared-linkable-true/threading-multi/exceptions.o" "/home/quantum/boost_1_33_1/libs/thread/build/../src/exceptions.cpp"
I've only snipped the error messages, but g++ is not my compiler. I've set CXX=i386-unknown-openbsd3.8-eg++, 'cause that's what its named on OpenBSD when you build a compiler from ports.
I know it's not the norm. But instead of CXX you need to set "GXX" and "GCC" as describe here http://www.boost.org/tools/build/v1/gcc-tools.html. You can set them directly on the bjam invocation as "-s" options as the example shows. HTH. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Quantum Skyline wrote:
-bash-3.00# ./bjam -sTOOLS=gcc --without-python --with-thread "-d+2" ... set -e "g++" -c -Wall -ftemplate-depth-255 -DNDEBUG -DNDEBUG -DBOOST_THREAD_LIB_NAME=boost_thread -DBOOST_THREAD_BUILD_DLL=1 -O3 -finline-functions -Wno-inline -pthread -fPIC -I"bin/boost/libs/thread/build" -I "/home/quantum/boost_1_33_1" -o "bin/boost/libs/thread/build/libboost_thread.so/gcc/release/shared-linkable-true/threading-multi/exceptions.o" "/home/quantum/boost_1_33_1/libs/thread/build/../src/exceptions.cpp"
I've only snipped the error messages, but g++ is not my compiler. I've set CXX=i386-unknown-openbsd3.8-eg++, 'cause that's what its named on OpenBSD when you build a compiler from ports.
I know it's not the norm. But instead of CXX you need to set "GXX" and "GCC" as describe here http://www.boost.org/tools/build/v1/gcc-tools.html. You can set them directly on the bjam invocation as "-s" options as the example shows.
HTH.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Thanks Rene, that definitely solves the issue of picking up the right compiler but I'm still getting the "threading support is not turned on" error message.
Thanks Rene, that definitely solves the issue of picking up the right compiler but I'm still getting the "threading support is not turned on" error message.
Can you try: cd into libs/thread/build then: bjam -d2 -sGXX=my-g++-executable stage and report the results? First command line only should do it. Can you also double check (yes I know again) that both patches I sent you are applied to the Boost tree you're building from (I get the impression you have more than one?). And if all else fails: Boost.Thread is just a bunch of sources, so you can build it yourself any way you want :-) John.
participants (4)
-
John Maddock -
Quantum Skyline -
Rene Rivera -
Todd Jackson