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

[Scott A. Smith]

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)
2.) Need to have Cygwin Python installed    (but not sources)
3.) It is convenient to have Windows Python (?, but in principle NOT?)
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)

And the oddity is that I use Windows Python to set PYTHON_ROOT because
it contains the Python Lib subdirectory. 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. In additon, /usr/lib is set one and the same with /lib.

> 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?

> 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. Maybe this is different if the sources are installed too
or if Python is built by the user.

> 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.

> For a Cygwin build you /will/ need the #includes as well (which
> according to your previous message you already have).

Yes these are in /usr/include/Python2.2

> In theory, you should be able to set PYTHON_ROOT to c:/cygwin/usr, but
> I don't think it actually will make a difference if you set
> PYTHON_STDLIB_PATH.

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. 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.

> If you are seeing -foptimize-sibling-calls, something is wrong with the
> Boost release. This was not supposed to be in the release and was fixed in
> the right place, but I guess it crept in. Please find
> tools/build/python.jam and change the line which reads:
>
>       <inlining>on <cxxflags>-foptimize-sibling-calls
>
> to read:
>
>       <inlining>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\runt
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

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

g++  -Wl,--export-all-symbols -Wl,--exclude-symbols,
.....  -lpython2.2.dll -lutil

...failed gcc-Link-action
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\boost_python.dll
..\..\..\libs\python\build\bin\boost_python.dll\gcc\release\inlining-on\runt
ime-link-dynamic\boost_python.lib...
...skipped
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
amic>boost_python.dll for lack of
<libs!python!build\boost_python.dll\gcc\release\inlining-on\runtime-link-dyn
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-dyn
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-dyn
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?

Scott

-----------------------------------------
-----------------------------------------

 Dr. Scott A. Smith
 Associate in Research
 National High Magnetic Field Laboratory
 1800 East Paul Dirac Drive
 Tallahassee, FL 32310

 phone: (850) 644-6348
 FAX:   (850) 644-1366
 email: ssmith at magnet.fsu.edu
 http://www.magnet.fsu.edu
 http://gamma.magnet.fsu.edu>