[C++-sig] Re: Problem building boost.python for Cygwin
dave at boost-consulting.com
Fri Feb 21 09:11:18 CET 2003
Marc, you might want to skip to the end of this message, then come
back and re-read ;-)
Marc Paterno <paterno at fnal.gov> writes:
> Yes, I have read the documentation at
> that's home I got as far as I did. I have built boost.python with no
> problems on Linux. But building for Cygwin has turned out to be much harder.
> Previously I was trying to use the Cygwin version of bjam to do the
> build; I have now switched to using the Windows version of bjam.
> I still do not understand the environment in which I am expected to
> work. Should I be running the build from a (Cygwin) bash shell, or
> from a Windows command prompt?
Windows command prompt, though bash may work.
> The second (working in a Windows command prompt) seems impossible,
> because the GCC compiler version I have requires the Cygwin dll to
> run; it must be used from a Cygwin command prompt.
Unless it's different from all the different Cygwin GCCs I've used
(and I've used every version from 2.95.3 on), it works just fine from
the NT command prompt.
> If I try the first method, do I need to define the paths in the
> environment variables in the Windows manner (because the Windows bjam
> will be using them to find files and directories), or should they be
> defined in the Cygwin path style, because g++ will be using them to
> find files and directories? Or is there a mixture? Below detail my
> best guesses, which are clearly still not right.
It doesn't matter; both bjam and g++ are insensitive to path style.
Here's what I do to build with the Python and the g++ (3.2) that's
currently installed by default with Cygwin:
The first line actually points to my regular Windows Python
installation, but when I'm building with GCC that's just there to keep
bjam happy; What's really important is that the PYTHON_STDLIB_PATH,
which defaults to $(PYTHON_ROOT)/Lib, has at least one .py file in it.
> Finally, although I have read the instructions at the web page listed
> above, I still have questions about where the environment variables
> should point. This is distinct from, and in addition to, my questions
> about *how* they should point there, via Cygwin-style or Windows-style
This is really a mess for Cygwin-only users. I'm sorry about it, but
I'll try to explain it well.
> 1) PYTHON_ROOT : "The root directory of your Python installation"
> Is this the directory in which the Python interpreter executable is to
> be found?
Only if you also have a regular windows installation. If you're just
building with Cygwin GCC it doesn't matter how you set this.
> 2) PYTHON_VERSION -- even I understand this one. I used
> export PYTHON_VERSION=2.2
Yeah; the default also works so you can leave this one out.
> 3) PYTHON_INCLUDES : "Path to Python #include directories". This
> seemed clear, but again I'm not sure if we want a Cygwin or Windows
> style path. I guessed Cygwin, because GCC will be passed the
> translated value, and GCC needs the Cygwin style pathnames.
> export PYTHON_INCLUDES=/usr/include/python2.2
It doesn't matter what style you use, and PYTHON_INCLUDES isn't used
when building from Windows. For Cygwin, you want GCC_PYTHON_ROOT to
point two directories above this one.
> This is the directory that contains Python.h, as well as many other
> 4) PYTHON_LIB_PATH : "Path to Python library object".
> I'm guessing that the "Python library object" for Cygwin's Python is
> the file /usr/lib/python2.2/config/libpython2.2.dll.a. When I use
> SWIG, under Cygwin, this is the file to which I link. My guess is that
> GCC will be driving the linker, and that I need to use the Cygwin path
> here, so that the linker can find the file. So:
> export PYTHON_LIB_PATH=/usr/lib/python2.2/config
This will be derived from GCC_PYTHON_ROOT, but it's fine to set it
> 5) PYTHON_STDLIB_PATH : "Path to Python standard library modules".
> I'm guessing that this means the directory in which the many .py,
> .pyc, and .pyo files for Python's standard library live; it also
> contains subdirectories for other standard library modules. I guessed
> that again I should use the Cygwin path, but this time is really a
> guess, with not much of a reason -- only that so far all the others
> have been Cygwin paths as well.
> export PYTHON_STDLIB_PATH=/usr/lib/python2.2
As I said, for Cygwin this just has to be any directory with a .py
file in it :(
> 6) CYGWIN_ROOT : "Path to user's Cygwin installation"
> Since the Cygwin path would always be trivially "/", it would seem
> this must mean the Windows path to the Cygwin root directory.
> export CYGWIN_ROOT=c:/cygwin
> I used the forward slash, rather than backward slash, following the
> style in the default for PYTHON_ROOT under Windows.
Either way will work.
> 7) GCC_PYTHON_ROOT : "Path to the user's Cygwin Python installation"
> Guessing Cygwin or Windows style here was also a bit hard, but since
> PYTHON_ROOT was already set to the Cygwin style path, I guessed the
> reason for this environment variable was to have a Windows-path
> equivalent. So:
> export GCC_PYTHON_ROOT=c:/cygwin/bin
> This is the Windows path to the directory in which the Cygwin python
> interpreter executable can be found.
stick with /usr or c:/cygwin/usr
> 8) GCC_DEBUG_PYTHON_ROOT : "Path to the users Cygwin pydebug build"
> I have no debug build of Python; I did not build the Python executable
> I'm using. I installed the pre-built package supplied by the good folk
> at Cygnus.
> I left this environment variable undefined, in the hopes that
> specifying -sBUILD=release" at the bjam command line would not
> actually require the use of this environment variable.
That's fine, and it also works for -sBUILD=debug. Only if you do
-sBUILD=debug-python will it fail.
> So, with this setup, from a Cygwin bash shell, using the Windows
> version of bjam, I try:
As I said, I've suceeded with this only from an NT shell. Well, hey,
let me try from a Cygwin shell:
$ cd $BOOST_ROOT/tools/build/jam_src
$ export PATH=$BOOST_ROOT/tools/build/jam_src/bin.cygwinx86:$PATH
$ cd $BOOST_ROOT/libs/python/test
$ bjam test
<lots and lots of bugfixes, etc.>
You'll need to checkout the latest CVS; you might want to look at the
updated building docs as well.
More information about the Cplusplus-sig