[C++-sig] Cygwin Boost.Python Build

[David Abrahams]

----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>


> Hi Dave,
>
> Not sure if I am getting less confused or not. When and if this
> build is ever working I'll redo the whole thing on a different machine
> with CygWin to make sure it works!
>
> Let me see if I fathom this so far:
>
> 1.) Need prebuilt jam for windows           (not cygwin built jam)

check

> 2.) Need to have Cygwin Python installed    (but not sources)

check. Headers and libraries, but not sources

> 3.) It is convenient to have Windows Python (?, but in principle NOT?)

Convenient but probably not neccessary if you set PYTHON_STDLIB_PATH
properly.

> 4.) Set the following variables
>         PYTHON_ROOT                         (C:\PROGRA~1\Python22)
>         PYTHON_VERSION                      (2.2)
>         CYGWIN_ROOT                         (C:\cywin)
>         GCC_PYTHON_ROOT                     (C:\cygwin\usr)

Looks OK

> And the oddity is that I use Windows Python to set PYTHON_ROOT because
> it contains the Python Lib subdirectory.

Yes. Or set PYTHON_STDLIB_PATH to c:/cygwin/usr/lib/python2.2

> To be sure, on a different
> PC I installed Cygwin Python via their setup to see what was put on the
> system. It placed files in /usr/lib/Python2.2 (py, pyo, etc.) and in
> /usr/include/Python2.2 (headers). Neither of these has any Lib
subdirectory
> stemming off of it.

Right.

> In additon, /usr/lib is set one and the same with /lib.

Huh? You mean there's a link?

> > Yes, you do. However, the helpful configuration checking is slightly
> > broken; if you're building with Cygwin your windows python will be
largely
> > ignored, but it still expects to find the right material in the
ordinary
> > Windows relationship to PYTHON_ROOT.
>
> Yes I do meaning I need just cygwin build python, just windows built
python,
> or both?

Going back to look at the context which you snipped,

> In a previous e-mail you said that I needed to have Cygwin built Python,
> not Windows Python!

Yes, you do (need a Cygwin built Python)

> > You can get around the "no python
> > installation" message by setting PYTHON_STDLIB_PATH to point at your
> > Cygwin python's Lib/ directory.
>
> As I said, a Cygwin Python install (via their setup) does not produce any
> Lib subdirectory.

Sorry. whatever Directory contains the standard libs. In your installation
it will be c:/cygwin/usr/lib/python2.2

> Maybe this is different if the sources are installed too
> or if Python is built by the user.

No, I just mis-named it.

> > There is at least a Lib/ directory; that contains the Python standard
> > library which is full of .py files.
>
> I would guess this is /usr/lib/Python2.2 but it is not a Lib directory
> off of Python. Yes, I compared its contents with the Windows Python Lib
> subdirectory and they share many of the same files.

Yes, that's the one.

> It looks to me as if only the Cygwin Python would suffice if it has the
> proper directory structure that the Jam stuff expects. Maybe simple links
> would work.

Don't bother; just set PYTHON_STDLIB_PATH as described above.

> One that set up some Lib subdirectory pointing to the where the
> python files, e.g.   ln -s /usr/lib/Python2.2 /usr/Lib so that
c:/cygwin/usr
> If you think that might work I'll give it a try, but in the meantime
there
> is the bigger build problem I hoped you could comment on.

> Done and that did help. There was a warning and what appeared to be
errors,
> but a dll was created!!? But did this actually work even with errors?
> Here is sections of the output:
>
> bjam -sTOOLS=gcc -sBUILD=release
> ...found 260 targets...
> ...updating 14 targets...
> .
> .
> gcc-C++-action
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\conversions.
> obj
> ../src\conversions.cpp: In function `struct PyObject *
> integer_to_python<signed char>(signed char)':
> ../src\conversions.cpp:153:   instantiated from here
> ../src\conversions.cpp:72: warning: `long int value_as_long' might be
used
> uninitialized in this function

It's OK; get a newer GCC if you don't want to see that.

> .
> gcc-C++-action
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\errors.obj
> gcc-Link-action
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\boost_python.dll
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\boost_python.lib
> g++: Files/Python22/libs: No such file or directory
> g++: Files/Python22/PCBuild: No such file or directory

These are a consequence of my not having tested the build with just Cygwin
on my machine... and some missing quotes in tools/build/gcc-tools.jam.
Arrggh!

The enclosed patch fixes the problems.

> g++  -Wl,--export-all-symbols -Wl,--exclude-symbols,
> .....  -lpython2.2.dll -lutil
>
> ...failed gcc-Link-action

Really, it failed and still generated output? That's odd. Normally jam
removes the product when a build step fails.

>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\boost_python.dll
>
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\run
t
> ime-link-dynamic\boost_python.lib...
> ...skipped
>
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dy
n
> amic>boost_python.dll for lack of
>
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dy
n
> amic>boost_python.lib...
> ...skipped <!libs!python!build!bin-stage>boost_python.dll for lack of
>
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dy
n
> amic>boost_python.dll...
> ...skipped <!libs!python!build!bin-stage>boost_python.lib for lack of
>
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dy
n
> amic>boost_python.lib...
> ...failed updating 1 target...
> ...skipped 3 targets...
> ...updated 10 targets...
>
> The bin-stage directory contains boost-python.lib (~1MB) and
> boost-python.dll (~330K). Hmm, then are the above fail messages
> not of any consequence?

Gee, I don't know. Why was it trying to build multiple versions of the
library, I wonder? What is your BUILD variable set to?

Sorry this is turning out to be so rough,

-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 622 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20020524/4ab6ecdf/attachment.obj>