Problems compiling boost.python with Boost 1.31.0

I'm trying to compile boost.python from Boost 1.31.0 on Tru64 5.1 with Compaq C++ V6.5-033. Python has been built like this: ./configure --with-cxx=cxx --prefix=/opt --exec-prefix=/opt/exec/OSF1-V5.1-a lpha --without-gcc The command line used to build boost.python looks like this: bjam -sTOOLS=tru64cxx65 -sPYTHON_ROOT="/opt" -sPYTHON_VERSION="2.3" stage When build boost.python I get the following error message: tru64cxx65-C++-action bin/boost/libs/python/build/libboost_python.so/tru64cxx65/debug/numeric.o cxx: Error: /net/camos/opt/include/python2.3/Python.h, line 8: #5 could not open source file "pyconfig.h" #include "pyconfig.h" ---------------------^ It looks like the exec prefix is not taken into account because the file is located here: /opt/exec/OSF1-V5.1-alpha/include/python2.3/pyconfig.h Is this not supported by the current boost build process or is there any option I missed? Or is there anything else I'm doing wrong? Thanks, Markus

"Markus Schöpflin" <markus.schoepflin@comsoft.de> writes:
I'm trying to compile boost.python from Boost 1.31.0 on Tru64 5.1 with Compaq C++ V6.5-033.
Python has been built like this:
./configure --with-cxx=cxx --prefix=/opt --exec-prefix=/opt/exec/OSF1-V5.1-a lpha --without-gcc
The command line used to build boost.python looks like this:
bjam -sTOOLS=tru64cxx65 -sPYTHON_ROOT="/opt" -sPYTHON_VERSION="2.3" stage
When build boost.python I get the following error message:
tru64cxx65-C++-action bin/boost/libs/python/build/libboost_python.so/tru64cxx65/debug/numeric.o cxx: Error: /net/camos/opt/include/python2.3/Python.h, line 8: #5 could not open source file "pyconfig.h" #include "pyconfig.h" ---------------------^
It looks like the exec prefix is not taken into account because the file is located here:
/opt/exec/OSF1-V5.1-alpha/include/python2.3/pyconfig.h
Is this not supported by the current boost build process or is there any option I missed? Or is there anything else I'm doing wrong?
I don't know. After bjam encounters an error it dumps the command-line it used to invoke the compiler. Do you see anything suspicious in that? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

David Abrahams wrote:
"Markus Schöpflin" <markus.schoepflin@comsoft.de> writes:
It looks like the exec prefix is not taken into account because the file is located here:
/opt/exec/OSF1-V5.1-alpha/include/python2.3/pyconfig.h
Is this not supported by the current boost build process or is there any option I missed? Or is there anything else I'm doing wrong?
I don't know. After bjam encounters an error it dumps the command-line it used to invoke the compiler. Do you see anything suspicious in that?
Ok, I have been digging a little deeper and I discovered several issues. After resolving all of them I was able to successfully compile boost.python. (Actually the build is still running but "libboost_python_debug.so" was built successfully.) 1. boost.python doesn't take into account the exec root. According to "http://www.python.org/doc/2.3.3/api/includes.html" it needs to be included as well when if differs from the python root. I hacked "python.jam" to work around that, it's attached as patch 1. It has the problems that the python root ends up two times in the include path. Don't know how to fix this... 2. In the file "tru64cxx65-tools.jam" the option "-nopure_cname" is passed to the compiler. This leads to problems when compiling io headers when "-std strict_ansi" is in effect, patch 2 fixes this. 3. boost.python doesn't include "Python.h" before including system headers. This leads to many warnings concerning the redefinitions of certain macros, like for example "_XOPEN_SOURCE" or "_POSIX_C_SOURCE". I fixed that by simply adding "#include <Python.h>" to the beginning of "/boost/python/detail/prefix.hpp". According to the comments in that file this problem is known. A better fix for this probably would be to manually include "pyconfig.h" before including any system headers, as this file defines all the macros giving trouble. 4. boost.python contains a workaround for the broken offsetof macro on Tru64/cxx. The version number for the check needs to be changed to include newer compilers as well. The latest cxx version I tried was V6.5-040, therefore I changed to version check to include that compiler. This is attached as patch 3. Thanks, Markus *** /usr/users/schoepf/net/src/boost_1_31_0/tools/build/v1/python.jam Wed Jan 28 22:52:25 2004 --- python.jam Thu Apr 15 08:28:51 2004 *************** *** 118,124 **** { PYTHON_ROOT ?= /usr/local ; PYTHON_ROOT = $(PYTHON_ROOT:J=" ") ; ! PYTHON_INCLUDES ?= $(PYTHON_ROOT)/include/python$(PYTHON_VERSION) ; PYTHON_LIB_PATH ?= $(PYTHON_ROOT)/lib/python$(PYTHON_VERSION)/config ; PYTHON_PROPERTIES ?= --- 118,125 ---- { PYTHON_ROOT ?= /usr/local ; PYTHON_ROOT = $(PYTHON_ROOT:J=" ") ; ! PYTHON_EXEC_ROOT ?= $(PYTHON_ROOT) ; ! PYTHON_INCLUDES ?= $(PYTHON_ROOT)/include/python$(PYTHON_VERSION) $(PYTHON_EXEC_ROOT)/include/python$(PYTHON_VERSION) ; PYTHON_LIB_PATH ?= $(PYTHON_ROOT)/lib/python$(PYTHON_VERSION)/config ; PYTHON_PROPERTIES ?= *** /usr/users/schoepf/net/src/boost_1_31_0/tools/build/v1/tru64cxx65-tools.jam Thu Aug 22 18:59:27 2002 --- tru64cxx65-tools.jam Thu Apr 15 09:04:57 2004 *************** *** 86,92 **** # really can't ignore this one! actions tru64cxx65-C++-action { ! cxx -ptr "$(<[1]:D)"/cxx_repository -noimplicit_include -c -std strict_ansi -nopure_cname -msg_display_number -msg_disable 186,450,1115 -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)" } #### Archive #### --- 86,92 ---- # really can't ignore this one! actions tru64cxx65-C++-action { ! cxx -ptr "$(<[1]:D)"/cxx_repository -noimplicit_include -c -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)" } #### Archive #### *** /usr/users/schoepf/net/src/boost_1_31_0/boost/python/detail/config.hpp Tue Jul 22 00:06:41 2003 --- config.hpp Thu Apr 15 09:28:09 2004 *************** *** 100,106 **** # define BOOST_PYTHON_EXPORT_CLASS_TEMPLATE(instantiation) struct ThIsTyPeNeVeRuSeD #endif ! #if (defined(__DECCXX_VER) && __DECCXX_VER <= 60590031) // Replace broken Tru64/cxx offsetof macro # define BOOST_PYTHON_OFFSETOF(s_name, s_member) \ ((size_t)__INTADDR__(&(((s_name *)0)->s_member))) --- 100,106 ---- # define BOOST_PYTHON_EXPORT_CLASS_TEMPLATE(instantiation) struct ThIsTyPeNeVeRuSeD #endif ! #if (defined(__DECCXX_VER) && __DECCXX_VER <= 60590040) // Replace broken Tru64/cxx offsetof macro # define BOOST_PYTHON_OFFSETOF(s_name, s_member) \ ((size_t)__INTADDR__(&(((s_name *)0)->s_member)))

<resent to the list, it never appeared via gmane> Markus Schöpflin wrote:
2. In the file "tru64cxx65-tools.jam" the option "-nopure_cname" is passed to the compiler. This leads to problems when compiling io headers when "-std strict_ansi" is in effect, patch 2 fixes this.
... and removing -nopure_cname leads to problems when boost.filesystem is beeing compiled... :-( I think I'll need to look for another fix. Markus
participants (3)
-
David Abrahams
-
Markus Schöpflin
-
Markus Sch�pflin