Boost V1 build on Solaris
I'm trying to build V1 boost::python on Solaris from boost_1_28. tersk06> $GCC_ROOT_DIRECTORY/bin/gcc -v Reading specs from /afs/slac/package/gcc/gcc-3/3.1.1/sun4x_58/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.1.1/specs Configured with: ../../src/gcc-3.1.1/configure --disable-libffi --without-libffi --prefix=/afs/slac.stanford.edu/package/gcc/gcc-3/3.1.1/sun4x_58 --srcdir=../../src/gcc-3.1.1 --enable-shared --enable-version-specific-runtime-libs Thread model: posix gcc version 3.1.1 tersk06> pwd /a/surrey07/g.ek.novadata/data/pfkeb/boost_1_28_0 tersk06> bjam "-sTOOLS=gcc" --------------------------------------------------------------------- skipping Boost.Python library build You can configure the location of your python installation, by setting: PYTHON_ROOT - currently "/afs/slac/package/python/sun4x_59/2.0" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.0" The following are automatically configured from PYTHON_ROOT if not otherwise set: PYTHON_INCLUDES - path to Python #include directories; currently "/afs/slac/package/python/sun4x_59/2.0/include/python2.0" PYTHON_LIB_PATH - path to Python library; currently "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0/config" PYTHON_STDLIB_PATH - path to Python standard library modules; currently "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0" --------------------------------------------------------------------- ...found 414 targets... So the rest of boost built but not python. I've not had problems under Linux. Any hints?
"Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU> writes:
I'm trying to build V1 boost::python on Solaris from boost_1_28.
tersk06> $GCC_ROOT_DIRECTORY/bin/gcc -v Reading specs from /afs/slac/package/gcc/gcc-3/3.1.1/sun4x_58/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.1.1/specs Configured with: ../../src/gcc-3.1.1/configure --disable-libffi --without-libffi --prefix=/afs/slac.stanford.edu/package/gcc/gcc-3/3.1.1/sun4x_58 --srcdir=../../src/gcc-3.1.1 --enable-shared --enable-version-specific-runtime-libs Thread model: posix gcc version 3.1.1
tersk06> pwd /a/surrey07/g.ek.novadata/data/pfkeb/boost_1_28_0
tersk06> bjam "-sTOOLS=gcc" --------------------------------------------------------------------- skipping Boost.Python library build You can configure the location of your python installation, by setting: PYTHON_ROOT - currently "/afs/slac/package/python/sun4x_59/2.0" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.0"
The following are automatically configured from PYTHON_ROOT if not otherwise set: PYTHON_INCLUDES - path to Python #include directories; currently "/afs/slac/package/python/sun4x_59/2.0/include/python2.0" PYTHON_LIB_PATH - path to Python library; currently "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0/config" PYTHON_STDLIB_PATH - path to Python standard library modules; currently "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0" --------------------------------------------------------------------- ...found 414 targets...
So the rest of boost built but not python. I've not had problems under Linux.
Any hints?
make sure there is an empty file at: /afs/slac/package/python/sun4x_59/2.0/lib/python2.0/test/__init__.py If there isn't one there already, add it. This will not mess up your python installation, and will make bjam happy. HTH, -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Building C/C++ Extensions for Python: Dec 9-11, Austin, TX http://www.enthought.com/training/building_extensions.html
On Wed, 23 Oct 2002 13:27:01 -0400, David Abrahams <dave@boost-consulting.com> said:
make sure there is an empty file at:
/afs/slac/package/python/sun4x_59/2.0/lib/python2.0/test/__init__.py
Thanks for the rapid response. In the meantime, I discovered that the python2.0/include directory only contains config.h. So the sys admins have not installed Python correctly. Grrr.
I finally got bjam to compile boost::python sources (if you remember my previous post, I found the Python header files is a strange place). Now I'm failing on the link step... /afs/slac/package/gcc/gcc-3/3.1.1/sun4x_58/bin/g++ -s -fPIC -shared -o "libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/runtime-link-dynamic/shared-linkable-true/libboost_python.so" < ..munch..> /bin/libboost_python.so/gcc/release/inlining-on/runtime-link-dynamic/shared-linkable-true/errors.o" -lutil ld: fatal: library -lutil: not found On my Linux machine, libutil.so appears in /usr/lib. and libra3> rpm -q --file /usr/lib/libutil.a glibc-devel-2.2.4-29 libutil.so doesn't appear to be on Solaris 5.8. Is there some other library I could link to? Do I really need libutil.so?
"Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU> writes:
I finally got bjam to compile boost::python sources (if you remember my previous post, I found the Python header files is a strange place). Now I'm failing on the link step...
/afs/slac/package/gcc/gcc-3/3.1.1/sun4x_58/bin/g++ -s -fPIC -shared -o "libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/runtime-link-dynamic/shared-linkable-true/libboost_python.so"
< ..munch..>
/bin/libboost_python.so/gcc/release/inlining-on/runtime-link-dynamic/shared-linkable-true/errors.o" -lutil
ld: fatal: library -lutil: not found
On my Linux machine, libutil.so appears in /usr/lib. and
libra3> rpm -q --file /usr/lib/libutil.a glibc-devel-2.2.4-29
libutil.so doesn't appear to be on Solaris 5.8. Is there some other library I could link to? Do I really need libutil.so?
I think you don't. If you want to manually edit $BOOST_ROOT/tools/build/python.jam to remove mention of <find-library>util or -lutil that might be your best bet. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Building C/C++ Extensions for Python: Dec 9-11, Austin, TX http://www.enthought.com/training/building_extensions.html
On Wed, 23 Oct 2002 17:01:10 -0400, David Abrahams <dave@boost-consulting.com> said:
I think you don't. If you want to manually edit $BOOST_ROOT/tools/build/python.jam to remove mention of <find-library>util or -lutil that might be your best bet.
That fixed it! Thanks again.
One final question, which is not specific to boost::python but general question on building Python modules. What my Solaris administrators have done is to configure Python with
./configure --prefix=/afs/.slac.stanford.edu/package/python/common/2.0 --exec-prefix=/afs/.slac.stanford.edu/package/python/sun4x_55/2.0
They also did a build fron Linux with the appropriate `exec-prefix'. What apparently this has done is to put all but one of the Python include files in the directory `common/2.0/include'. But Python.h includes `config.h' or `pyconfig.h' (depending on the version) which gets installed in `sun4x_55/2.0/include'. This is appropriate since this file is machine/OS dependent. Now the problem is that boost::python, and other packages, gives you one variable, like PYTHON_INCLUDES, for its build. When it is set to find `Python.h' it will not find `pyconfig.h'. What is the best way to handle this situation? Is it a bug in Python's configure script? Bug in boost::python and others? Or am I missing something obvious?
On Wed, 2002-10-23 at 22:36, Paul F. Kunz wrote:
One final question, which is not specific to boost::python but general question on building Python modules. What my Solaris administrators have done is to configure Python with
./configure --prefix=/afs/.slac.stanford.edu/package/python/common/2.0 --exec-prefix=/afs/.slac.stanford.edu/package/python/sun4x_55/2.0
They also did a build fron Linux with the appropriate `exec-prefix'. What apparently this has done is to put all but one of the Python include files in the directory `common/2.0/include'. But Python.h includes `config.h' or `pyconfig.h' (depending on the version) which gets installed in `sun4x_55/2.0/include'. This is appropriate since this file is machine/OS dependent.
Now the problem is that boost::python, and other packages, gives you one variable, like PYTHON_INCLUDES, for its build. When it is set to find `Python.h' it will not find `pyconfig.h'.
What is the best way to handle this situation? Is it a bug in Python's configure script? Bug in boost::python and others? Or am I missing something obvious?
Your setup requires that sun4x_55/2.0/include is in the include path somehow (i.e. it should be in the -I parameter of all compiler invocations). Reading <boost>tools/build/gcc-tools.jam makes me believe that you can make your setup work by adding the following line to your <boost>/Jamrules file: STDHDRS += /afs/.slac.stanford.edu/package/python/sun4x_55/2.0 IMO, the proper way to fix this would be to make boost.python accept a PYTHON_EXECUTABLE variable which we could set like: PYTHON_EXECUTABLE ?= /usr/local/bin/python2.2 This way, boost could probe python for its version and distutil infrastructure for all apropriate include and link flags. This is what Psycopg does in it's ./configure script (e.g. --with-python=...) -- Ideas don't stay in some minds very long because they don't like solitary confinement.
Leonardo Rochael Almeida <leo@hiper.com.br> writes:
On Wed, 2002-10-23 at 22:36, Paul F. Kunz wrote:
One final question, which is not specific to boost::python but general question on building Python modules. What my Solaris administrators have done is to configure Python with
./configure --prefix=/afs/.slac.stanford.edu/package/python/common/2.0 --exec-prefix=/afs/.slac.stanford.edu/package/python/sun4x_55/2.0
They also did a build fron Linux with the appropriate `exec-prefix'. What apparently this has done is to put all but one of the Python include files in the directory `common/2.0/include'. But Python.h includes `config.h' or `pyconfig.h' (depending on the version) which gets installed in `sun4x_55/2.0/include'. This is appropriate since this file is machine/OS dependent.
Now the problem is that boost::python, and other packages, gives you one variable, like PYTHON_INCLUDES, for its build. When it is set to find `Python.h' it will not find `pyconfig.h'.
What is the best way to handle this situation? Is it a bug in Python's configure script? Bug in boost::python and others? Or am I missing something obvious?
Your setup requires that sun4x_55/2.0/include is in the include path somehow (i.e. it should be in the -I parameter of all compiler invocations). Reading <boost>tools/build/gcc-tools.jam makes me believe that you can make your setup work by adding the following line to your <boost>/Jamrules file:
STDHDRS += /afs/.slac.stanford.edu/package/python/sun4x_55/2.0
That's generally /not/ the way you're intended to use the build system. You can do this, but it's not going to work in future versions of the build system and it could do unexpected things when you build targets other than Boost.Python and Boost.Python extensions. The right thing to do is to add something like: PYTHON_PROPERTIES += <sysinclude>$(PYTHON:D)/include ; to the end of tools/build/python.jam, but I don't want to make that change until I hear from python-dev about what's going on here. In the meantime, you can do it in the Jamfiles after python.jam is included. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Building C/C++ Extensions for Python: Dec 9-11, Austin, TX http://www.enthought.com/training/building_extensions.html
Leonardo Rochael Almeida <leo@hiper.com.br> writes:
On Wed, 2002-10-23 at 22:36, Paul F. Kunz wrote:
One final question, which is not specific to boost::python but general question on building Python modules. What my Solaris administrators have done is to configure Python with
./configure --prefix=/afs/.slac.stanford.edu/package/python/common/2.0 --exec-prefix=/afs/.slac.stanford.edu/package/python/sun4x_55/2.0
They also did a build fron Linux with the appropriate `exec-prefix'. What apparently this has done is to put all but one of the Python include files in the directory `common/2.0/include'. But Python.h includes `config.h' or `pyconfig.h' (depending on the version) which gets installed in `sun4x_55/2.0/include'. This is appropriate since this file is machine/OS dependent.
Now the problem is that boost::python, and other packages, gives you one variable, like PYTHON_INCLUDES, for its build. When it is set to find `Python.h' it will not find `pyconfig.h'.
What is the best way to handle this situation? Is it a bug in Python's configure script? Bug in boost::python and others? Or am I missing something obvious?
Your setup requires that sun4x_55/2.0/include is in the include path somehow (i.e. it should be in the -I parameter of all compiler invocations). Reading <boost>tools/build/gcc-tools.jam makes me believe that you can make your setup work by adding the following line to your <boost>/Jamrules file:
STDHDRS += /afs/.slac.stanford.edu/package/python/sun4x_55/2.0
That's generally /not/ the way you're intended to use the build system. You can do this, but it's not going to work in future versions of the build system and it could do unexpected things when you build targets other than Boost.Python and Boost.Python extensions. The right thing to do is to add something like: PYTHON_PROPERTIES += <sysinclude>$(PYTHON:D)/include ; to the end of tools/build/python.jam, but I don't want to make that change until I hear from python-dev about what's going on here. In the meantime, you can do it in the Jamfiles after python.jam is included. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Building C/C++ Extensions for Python: Dec 9-11, Austin, TX http://www.enthought.com/training/building_extensions.html
"Paul F. Kunz" <Paul_Kunz@SLAC.Stanford.EDU> writes:
One final question, which is not specific to boost::python but general question on building Python modules. What my Solaris administrators have done is to configure Python with
./configure --prefix=/afs/.slac.stanford.edu/package/python/common/2.0 --exec-prefix=/afs/.slac.stanford.edu/package/python/sun4x_55/2.0
They also did a build fron Linux with the appropriate `exec-prefix'. What apparently this has done is to put all but one of the Python include files in the directory `common/2.0/include'. But Python.h includes `config.h' or `pyconfig.h' (depending on the version) which gets installed in `sun4x_55/2.0/include'. This is appropriate since this file is machine/OS dependent.
Now the problem is that boost::python, and other packages, gives you one variable, like PYTHON_INCLUDES, for its build. When it is set to find `Python.h' it will not find `pyconfig.h'.
What is the best way to handle this situation? Is it a bug in Python's configure script? Bug in boost::python and others? Or am I missing something obvious?
Sorry it took so long to come up with an answer, Paul. It was staring me right in the face the whole time, though: You just need to make sure your PYTHON_INCLUDES variable has two elements. Depending on how your shell treats quotes, that could take several forms. The shells I have available, e.g. bash, will let you embed a space in a command-line argument as follows: bjam -sPYTHON_INCLUDES="/afs/.slac.stanford.edu/package/python/common/2.0/include /afs/.slac.stanford.edu/package/python/sun4x_55/2.0/include" ... And bjam splits up variable values on whitespace boundaries. Some shells let you set up variables with embedded spaces in the environment; you might try that if your shell doesn't cooperate when you try to use quotes in the command-line. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com
On Wed, 2002-10-23 at 14:55, Paul F. Kunz wrote:
I'm trying to build V1 boost::python on Solaris from boost_1_28.
tersk06> $GCC_ROOT_DIRECTORY/bin/gcc -v Reading specs from /afs/slac/package/gcc/gcc-3/3.1.1/sun4x_58/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.1.1/specs Configured with: ../../src/gcc-3.1.1/configure --disable-libffi --without-libffi --prefix=/afs/slac.stanford.edu/package/gcc/gcc-3/3.1.1/sun4x_58 --srcdir=../../src/gcc-3.1.1 --enable-shared --enable-version-specific-runtime-libs Thread model: posix gcc version 3.1.1
tersk06> pwd /a/surrey07/g.ek.novadata/data/pfkeb/boost_1_28_0
tersk06> bjam "-sTOOLS=gcc" --------------------------------------------------------------------- skipping Boost.Python library build You can configure the location of your python installation, by setting: PYTHON_ROOT - currently "/afs/slac/package/python/sun4x_59/2.0" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.0"
The following are automatically configured from PYTHON_ROOT if not otherwise set: PYTHON_INCLUDES - path to Python #include directories; currently "/afs/slac/package/python/sun4x_59/2.0/include/python2.0" PYTHON_LIB_PATH - path to Python library; currently "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0/config" PYTHON_STDLIB_PATH - path to Python standard library modules; currently "/afs/slac/package/python/sun4x_59/2.0/lib/python2.0" --------------------------------------------------------------------- ...found 414 targets...
So the rest of boost built but not python. I've not had problems under Linux.
Any hints?
_______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
edit Jamrules in your boost root dir. and add: PYTHON_ROOT ?= /usr/local ; PYTHON_VERSION ?= 2.2 ; replace /usr/local with whatever directory has bin/python and replace 2.2 with the first two levels of whatever version of python you have (e.g. 2.1, not 2.1.3). Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.
participants (3)
-
David Abrahams -
Leonardo Rochael Almeida -
Paul F. Kunz