Mailman 3 February 2003 - Cplusplus-sig

problem wrapping a c++ function on windows
by Alexandre Gillet Feb. 26, 2003

Feb. 26, 2003

Hi, I am trying to wrappe a library using swig on windows(windows 2000,swig1.3.11). I am able to build a dll but when I load my module videolib,I get the following error: the dynamic link library libARvideo.dll could not be found But I did get link with the library libARvideo.lib Here is my interface file videolib.i and the command I used to build my python module: %{ int arVideoOpen( char *config ); %} int arVideoOpen( char *config ); ########################################## Here is the swig command I used: H:\Swig\SWIG-1.3.11\swig.exe -python -dump_tree -shadow -c++ -no_default -DSWIG_RELEASE=1.3.11 -DSWIG_TYPE=python -IH:\Python\Python2.1\include -IH:\Python\Python2.1\PC -IH:\Python\Python2.1\Include -I..\..\include -D_WIN32 -IH:\Swig\SWIG-1.3.11\Lib -IH:\Swig\SWIG-1.3.11\Lib\python -module videolib -o videolib.swigout videolib.i > videolib.swigtree H:\Python\Python2.1\libplus\bin\pybatch.bat "H:\Python\Python2.1\libplus ;H:\ARToolKit\ARToolKit-DS-2.65b;H:\ARToolKit\ARToolKit-DS-2.65b\python/videopython" H:\Python\Python2.1\python21.exe -c "import tool; tool.run()" filter -i videolib.swigout -o videolib.precious.c H:\ARToolKit\ARToolKit-DS-2.65b\python\videopython>H:\Python\Python2.1\python21. exe -c "import tool; tool.run()" filter -i videolib.swigout -o videolib.precious Command use to compile: CL.EXE -c -nologo -W3 -Gy -Ox -GD -MD -DSWIG_RELEASE=1.3.11 -DSWIG_TYPE=python -IH:\Python\Python2.1\include -IH:\Python\Python2.1\PC -IH:\Python\Pythn2.1\Include -I..\..\include -F -o videolib.obj videolib.precious.c Link: link -debug -nologo -warn:3 -map -dll -export:initvideolibc -out:videolbc.dll videolib.obj -LIBPATH:..\..\lib libARvideo.lib -LIBPATH:H:\Python\Python2.1\libs python21.lib Any idea what I am doing wrong? In the Library the function I need to access is define in the .h file by: int __declspec(ddlexport) arVideoOpen( char *config ); Thanks -- o Alexandre Gillet email: gillet(a)scripps.edu / The Scripps Research Institute, o Dept. Molecular Biology, MB-5, \ 10550 North Torrey Pines Road, o La Jolla, CA 92037-1000, USA. / tel: (858) 784-2053 o fax: (858) 784-2860

2 1

Virtual methods
by Nicodemus Feb. 25, 2003

Feb. 25, 2003

Hi! I'm using Intel C++, STLport 4.5.3 and the current CVS. I can't get the simple example from the tutorial about virtual methods to work. I copied and pasted the example, but couldn't reproduce the correct behaviour in python: // basic.cpp #include <boost/python.hpp> using namespace boost::python; struct Base { virtual int f() = 0; }; int call_f(Base& b) { return b.f(); } struct BaseWrap : Base { BaseWrap(PyObject* self_) : self(self_) {} int f() { return call_method<int>(self, "f"); } PyObject* self; }; // Module ====================================================================== BOOST_PYTHON_MODULE(basic) { class_<Base, BaseWrap, boost::noncopyable>("Base", no_init) ; def("call_f", call_f); } >>> from basic import * >>> class Derived(Base): ... def f(self): ... return 42 ... >>> d = Derived() Traceback (most recent call last): File "<stdin>", line 1, in ? RuntimeError: This class cannot be instantiated from Python >>> >>> # hmmm... let's override the __init__ method and see >>> # what happens >>> class Derived(Base): ... def __init__(self): pass ... def f(self): return 42 ... >>> d = Derived() >>> call_f(d) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: bad argument type for built-in operation >>> I remember using this example before, and it did work... has something changed since then? Thanks, Nicodemus.

2 2

Re: boost.python answer - thanks!
by David Abrahams Feb. 25, 2003

Feb. 25, 2003

"mghiggins <mghiggins(a)yahoo.com>" <mghiggins(a)yahoo.com> writes: > Thanks, that helped a lot! As I asked you before, please post your Boost.Python questions to the C++-sig. > Another perhaps more basic question: how do I pass a python function > object to a C++ method and use it internally? e.g., if I have a class > > class Passer > { > public: > Passer() {}; > void setx( dict x ) { this->m_x = x; }; > void setf( object f ) { this->m_f = f; }; > double val(); > double xval() { return extract<double>( m_x['v'] ); }; > > private: > dict m_x; > object m_f; > }; > > double Passer::val() > { > PyObject * f = m_f.ptr(); > PyObject * ret = PyEval_CallObject( f, m_x.ptr() ); why not just object ret = m_f(m_x); ?? > double RetVal; > if( ret ) > RetVal = 1; > else > RetVal = -1; > > PyArg_Parse( ret, "(f)", &RetVal ); > return RetVal; > } I don't know what your PyArg_Parse thing is supposed to be doing. I'm not really sure what all of that 1/-1 stuff is about either. Is RetVal a tuple of one element? Maybe you want: double Passer::val() { return m_f(m_x)[0]; } > The setx method seems to work fine with a dictionary like {'v':4} and > the xval method returns its 'v' element properly. > > But the setf method doesn't seem to work correctly... when I call > val() from python after setting on a function, PyObject * ret comes > back NULL (which I learn from getting RetVal == -1 as a return value). That might just mean that f raised a Python exception. You're masking the problem by returning -1 instead of using the Boost.Python facilities which propagate the Python exception through your C++ code and back to Python. > I'm sure I'm doing something dumb by making the type of setf's arg be > "object" rather than something specifying a function, but I don't know > what. :) Anything obvious I'm missing here? The only dumb-ish thing is using the raw Python 'C' API instead of what Boost.Python gives you. Try the simple approach I outlined above; it might be revealing. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Re: C++ object from PyObject pointer
by David Abrahams Feb. 24, 2003

Feb. 24, 2003

The following message is a courtesy copy of an article that has been posted to gmane.comp.lib.boost.user as well. "mghiggins <mghiggins(a)yahoo.com>" <mghiggins(a)yahoo.com> writes: > Excuse my newbiness if this question is too dumb... :) > > I've built a python extension from a C++ class using boost - it all > seems to work fine. > > However, now another C++ function is receiving a pointer to a PyObject > that represents an instance of this "boosted" python class. How do I > pick off a pointer to the underlying C++ object from the PyObject > pointer? Boost.Python questions to the c++-sig, please! http://www.python.org/sigs/c++-sig/ Your answer: void f(PyObject* p) { handle<> ph(borrowed(p)); MyObj* op = extract<MyObj*>(object(ph)); } HTH, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: Problem building boost.python for Cygwin
by Marc Paterno Feb. 24, 2003

Feb. 24, 2003

Hello, Yes, I have read the documentation at http://www.boost.org/libs/python/doc/building.html#configuration; 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? 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. 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. 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 paths. 1) PYTHON_ROOT : "The root directory of your Python installation" Is this the directory in which the Python interpreter executable is to be found? The Windows filename for Cygwin's executable image for the Python interpreter is c:\cygwin\bin\python2.2.exe. The Cygwin filename for this file is /bin/python2.2.exe; it is also /usr/bin/python2.2.exe (my understanding is that Cygwin's internal manipulations make /bin and /usr/bin identical. When viewed from Windows, the directory c:\cygwin\usr\bin exists, but is empty). Finally, under Cygwin, /usr/bin/python is a symbolic link to /usr/bin/python2.2.exe. I have tried both export PYTHON_ROOT=/bin and export PYTHON_ROOT=c:/cygwin/bin (forward slashes, not backward slashes). 2) PYTHON_VERSION -- even I understand this one. I used export PYTHON_VERSION=2.2 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 This is the directory that contains Python.h, as well as many other headers. 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 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 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. 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. 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. So, with this setup, from a Cygwin bash shell, using the Windows version of bjam, I try: bjam -sTOOLS=gcc -sBUILD=release As I noted above, I tried both PYTHON_ROOT=c:/cygwin/bin and PYTHON_ROOT=/bin. Both attempts fail. With PYTHON_ROOT=c:/cygwin/bin, I get: build$ bjam -sTOOLS=gcc -sBUILD=release --------------------------------------------------------------------- skipping Boost.Python library build due to missing or incorrect configuration You can configure the location of your python installation by setting: PYTHON_ROOT - currently "c:/cygwin/bin" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.2" The following are automatically configured from PYTHON_ROOT if not otherwise set: GCC_PYTHON_ROOT - path to Cygwin Python installation; currently "c:/cygwin/bin" GCC_PYTHON_DEBUG_ROOT - path to Cygwin debug-python installation (configured --with-pydebug); currently "c:/cygwin/usr/local/pydebug" PYTHON_LIB_PATH - path to Python library; currently "/usr/lib/python2.2/config" PYTHON_STDLIB_PATH - path to Python standard library modules; currently "/usr/lib/python2.2" --------------------------------------------------------------------- ...found 8 targets... and with PYTHON_ROOT=/bin I get the similar (not quite identical) build$ bjam -sTOOLS=gcc -sBUILD=release --------------------------------------------------------------------- skipping Boost.Python library build due to missing or incorrect configuration You can configure the location of your python installation by setting: PYTHON_ROOT - currently "/bin" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.2" The following are automatically configured from PYTHON_ROOT if not otherwise set: GCC_PYTHON_ROOT - path to Cygwin Python installation; currently "c:/cygwin/bin" GCC_PYTHON_DEBUG_ROOT - path to Cygwin debug-python installation (configured --with-pydebug); currently "c:/cygwin/usr/local/pydebug" PYTHON_LIB_PATH - path to Python library; currently "/usr/lib/python2.2/config" PYTHON_STDLIB_PATH - path to Python standard library modules; currently "/usr/lib/python2.2" --------------------------------------------------------------------- ...found 8 targets... So, clearly I am still doing something wrong. Can someone point out the incorrect part(s) of my setup? best regards, Marc

2 3

implicitly_convertible<> & auto_ptr
by Nicolas Lelong Feb. 24, 2003

Feb. 24, 2003

Hi, I came to have some needs to are similar to those of Bruce Lowery in 'Inheritance with B/P' thread. In have a situation like this one: ---- class BigDataBase { }; class BigDataDerived : public BigDataBase { }; class BigDataStore { public: void addBigData(char const* name, std::auto_ptr<BigDataBase> data) { } }; //[...] python::class_<BigDataBase, std::auto_ptr<BigDataBase>, boost::noncopyable>("BigDataBase", python::no_init); python::class_<BigDataDerived, python::bases<BigDataBase>, std::auto_ptr<BigDataDerived>, boost::noncopyable>("BigDataDerived"); python::class_<BigDataStore, boost::noncopyable>("BigDataStore") .def("addBigData", &BigDataStore::addBigData, python::with_custodian_and_ward<1,2>() ); ---- Whenever I execute the python stuff below, I get the now famous 'bad argument type for built-in operation' : big = BigDataDerived() bigstore = BigDataStore() bigstore.addBigData('dumb', big) I catched the David's comment about adding in the module the following statement, which I thought could save my life : 'python::implicitly_convertible< std::auto_ptr<BigDataDerived>, std::auto_ptr<BigDataBase> >();' Alas, it doesn't compile here under VC7, the compiler complains about : 'std::auto_ptr<_Ty>::auto_ptr(std::auto_ptr<BigDataDerived> &)' : cannot convert parameter 1 from 'const std::auto_ptr<_Ty>' to 'std::auto_ptr<_Ty> &' with [ _Ty=BigDataBase ] and [ _Ty=BigDataDerived ] and [ _Ty=BigDataDerived ] Conversion loses qualifiers Can anyone tell me if this compile error is 'normal' or if it's another VC bug ? Can anyone point me in a direction that could help solving this transfer of ownership problem ? I tried to implement my own specialized type holder, without much success, i must admit... Thanks in advance Nicolas

4 6

Re : How to wrap this overloaded member function whose return type is reference ?
by horace(seednet) Feb. 22, 2003

Feb. 22, 2003

Dave Abrahams wrote : > Can you post the error message(s) you get? That would be a nice start. Ok, Dave, If you want to see those error messages, here you go. Last time I thought it wasn't too polite to dump those lengthy error messages here. for this line of code : .def_readonly("origin",&point3d::origin) I got D:\test\point3d.cpp(6) : error C2784: 'class boost::python::class_<class point3d,struct boost::python::detail::not_specified,struct boost::python::detail::not_specified,struct boost::python::detail::not_specified> &__thiscall boost::python::class_<class point3d,struct boost::python::detail::not_specified,struct boost::python::detail::not_specified,struct boost::python::detail::not_specified>::def_readonly(const char *, point3d::*)' : could not deduce template argument for ' point3d::*' from 'const class point3d *' for this line of code : .def("set",(point3d& (point3d::*)(double, double, double)) point3d::set,args("x", "y", "z")) I got d:\boost_1_29_0\boost/python/detail/returning.hpp(175) : error C2079: 'cr' uses undefined struct 'specify_a_result_policy_to_wrap_functions_returning<class point3d &>' d:\boost_1_29_0\boost/python/detail/caller.hpp(100) : see reference to function template instantiation 'struct _object *__cdecl boost::python::detail::returning<class point3d &>::call(class point3d &(__thiscall point3d::*)(double ,double,double),struct _object *,struct _object *,const struct boost::python::default_call_policies *)' being compiled d:\boost_1_29_0\boost/python/detail/returning.hpp(176) : error C2228: left of '.convertible' must have class/struct/union type d:\boost_1_29_0\boost/python/detail/caller.hpp(100) : see reference to function template instantiation 'struct _object *__cdecl boost::python::detail::returning<class point3d &>::call(class point3d &(__thiscall point3d::*)(double ,double,double),struct _object *,struct _object *,const struct boost::python::default_call_policies *)' being compiled d:\boost_1_29_0\boost/python/detail/returning.hpp(181) : error C2064: term does not evaluate to a function d:\boost_1_29_0\boost/python/detail/caller.hpp(100) : see reference to function template instantiation 'struct _object *__cdecl boost::python::detail::returning<class point3d &>::call(class point3d &(__thiscall point3d::*)(double ,double,double),struct _object *,struct _object *,const struct boost::python::default_call_policies *)' being compiled Error executing cl.exe. I think my problem in using Boost.Python is that I don't know what I'm doing.

3 3

How to wrap this overloaded member function whose return type is reference ?
by horace(seednet) Feb. 21, 2003

Feb. 21, 2003

I have one trouble class need to be wrapped, the code snippet looks like this : class point3d { public: point3d(); point3d(const point3d& pnt); point3d(double x, double y, double z); point3d& set(double x, double y, double z); point3d& set(const point3d& pnt); static const point3d origin; double x, y, z; }; This is what I have done : BOOST_PYTHON_MODULE(test) { class_<point3d>("point3d") .def(init<>()) // compiles ok .def(init<const point3d&>() // compiles ok .def(init<double,double,double>(args("x", "y", "z"))) // compiles ok // troublesome lines .def("set",(point3d& (point3d::*)(double, double, double)) point3d::set,args("x", "y", "z")) // this line doesn't compile .def("set",(point3d& (point3d::*)(const point3d& )) point3d::set) // this line doesn't compile .def_readonly("origin",&point3d::origin) // this line doesn't compile // .def_readwrite("x",&point3d::x) // compiles ok .def_readwrite("y",&point3d::y) // compiles ok .def_readwrite("z",&point3d::z) // compiles ok ; } The code don't compile. I can locate lines that cause the trouble, as shown above, but I don't know why. If I just comment those troublesome lines out, everything is fine, however I don't like to play ostrich all the time. Can anybody be so kind to tell me how to do it, or what's wrong in the code I have written ? Horace

2 1

special to_python for a particular function
by Daniel Holth Feb. 21, 2003

Feb. 21, 2003

Hi. I'm using C++ std::strings to hold my 8-bit clean data but the default to_python converter does not use string.size() to find the length. This means I get only up to the first null character back into Python. I wound up editing the boost library to fix this and it works great now, perhaps this bug is fixed in CVS Boost.Python already... I tried adding a new to_python in my declaration (without editing Boost.Python) but it seems to insist on using the old one. How can I have a special to_python for a particular function? Another example I don't know how to do is functions that give and take char* and int separately to mean a string and its length. Thanks. - Daniel Holth

3 2

Problem building boost.python for Cygwin
by Marc Paterno Feb. 20, 2003

Feb. 20, 2003

I have been attempting to build boost.python on Cygwin, and have encountered trouble. I hope that someone may be able to diagnose my problem. I am using Windows 2000 SP3 Cygwin v1.3.20-1 GCC 3.2 20020927 (prerelease) python 2.2.2 (on Cygwin) bjam 3.1.3 for Cygwin I am performing all builds from a Cygwin (bash) shell. I have been able to build the thread, signals, and regex libraries, so I am fairly sure that bjam and gcc are working properly. However, when I attempt to build boost.python, the build fails. Specifically, it seems that proper object files get built, in the directory libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ runtime-link-dynamic/shared-linkable-true/ (I split the directory name over two lines for readability; the name is not really split.) However, it seems that building of the dynamic library fails. Here is the output from running bjam a second time, after the .o files had been successfully built. ---------- $> bjam -sTOOLS=gcc -sBUILD=release ...patience... ...found 903 targets... ...updating 2 targets... gcc-Link-action ../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru ntime-link-dynamic/shared-linkable-true/libboost_python.so ../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru ntime-link-dynamic/shared-linkable-true/numeric.o(.text+x320):numeric.cpp: undefined reference to `_PyExc_ImportError' ../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru ntime-link-dynamic/shared-linkable-true/numeric.o(.text+x33d):numeric.cpp: undefined reference to `_PyErr_Format' ... about 700 similar lines removed ... ../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru ntime-link-dynamic/shared-linkable-true/object_operators.o(.text+x93f):objec t_operators.cpp: undefined reference to `_PyNumber_InPlaceXor' ../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru ntime-link-dynamic/shared-linkable-true/object_operators.o(.text+x9ff):objec t_operators.cpp: undefined reference to `_PyNumber_InPlaceOr' collect2: ld returned 1 exit status export LD_LIBRARY_PATH g++ -s -fPIC -shared -o "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/libboost_python.so" -L"/usr/lib/py thon2.2/config" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/numeric.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/list.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/long.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/dict.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/tuple.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/str.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/aix_init_module.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/from_python.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/registry.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/type_id.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/enum.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/class.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/function.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/inheritance.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/life_support.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/pickle_support.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/errors.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/module.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/builtin_converters.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/arg_to_python_base.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/iterator.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/object_protocol.o" "../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/r untime-link-dynamic/shared-linkable-true/object_operators.o" ...failed gcc-Link-action ../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/ru ntime-link-dynamic/shared-linkable-true/libboost_python.so... ...skipped <!libs!python!build!bin-stage>libboost_python.so for lack of <libs!python!build/libboost_python.so/gcc/release/inlining-on/runtime-link-d ynamic/shared-linkable-true>libboost_python.so... ...failed updating 1 target... ...skipped 1 target... ---------------------------------- Here are what I understand are the relevant environment variable settings I have established: PYTHON_ROOT=/usr/lib/python2.2 PYTHON_INCLUDES=/usr/include/python2.2 PYTHON_LIB_PATH=/usr/lib/python2.2/config PYTHON_STDLIB_PATH=/usr/lib/python2.2 PYTHON_VERSION=2.2 I am least sure about PYTHON_ROOT and PYTHON_LIB_PATH: PYTHON_ROOT is defined such that ${PYTHON_ROOT}/bin/python.exe is the full path to the Python executable; PYTHON_LIB_PATH is defined such that ${PYTHON_LIB_PATH}/libpython2.2.dll.a is the full path to the Python library supplied as a Cygwin 'package'. I suspect I have one (or more) of these defined wrongly, but haven't been able to find the right setting to make things go. Suggestions would be most welcome. best regards, Marc

3 2