Mail Archives: cygwin/2001/08/07/05:40:54
> BTW, the USE_DL_IMPORT macro, etc. is set automatically if the Cygwin
> Python extension is built via the Distutils or Misc/Makefile.pre.in
> method. My recommendation is to try to use Distutils, if possible,
> when building Python extensions.
Actually, now that you bring this up, here are my unsuccessful experiences
with cygwin python distutils. (Not sure if this is going off-topic here,
might be better suited for a distutils mailing list.)
$cat setup.py
from distutils.core import setup, Extension
setup(name="convert", version="1.0", \
ext_modules=[Extension("convert", ["convert.cpp"], \
library_dirs=["/users/pbienst/tmp/boost_cvs/libs/python/build"], \
include_dirs=["/users/pbienst/tmp/boost_cvs"], \
libraries=["boost_python"])])
$python setup.py -build --compiler-cygwin
running build
running build_ext
building 'convert' extension
creating build
creating build/temp.cygwin_nt-4.0-1.3.2-i686-2.1
gcc -mcygwin -mdll -O -Wall -I/users/pbienst/tmp/boost_cvs -I/usr/include/py
thon2.1 -c convert.cpp -o build/temp.cygwin_nt-4.0-1.3.2-i686-2.1/convert.o
writing build/temp.cygwin_nt-4.0-1.3.2-i686-2.1/convert.def
creating build/lib.cygwin_nt-4.0-1.3.2-i686-2.1
gcc -mcygwin -mdll -static -s
build/temp.cygwin_nt-4.0-1.3.2-i686-2.1/convert.o
build/temp.cygwin_nt-4.0-1.3.2-i686-2.1/convert.def -L/users/pbienst/tmp/boo
st_cvs/libs/python/build -L/usr/lib/python2.1/config -lboost_python -lpython
2.1 -o build/lib.cygwin_nt-4.0-1.3.2-i686-2.1/convert.dll
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld:
cannot find -lpython2.1
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
Weird, especially since -L/usr/lib/python2.1/config -lpython2.1 is in the
command line. Also note that gcc is used rather g++, although the extension
is cpp. There is also no trace of USE_DL_IMPORT.
Now, if I omit --compiler=cygwin:
$python setup.py build
running build
running build_ext
building 'convert' extension
creating build
creating build/temp.cygwin_nt-4.0-1.3.2-i686-2.1
gcc -g -O2 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -I/users/pbienst/tmp/bo
ost_cvs -I/usr/include/python2.1 -c convert.cpp -o
build/temp.cygwin_nt-4.0-1.3.2-i686-2.1/convert.o
creating build/lib.cygwin_nt-4.0-1.3.2-i686-2.1
gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin_nt-4.0-1.3.2-i686-2.1/convert.o -L/users/pbienst/tmp/boost
_cvs/libs/python/build -L/usr/lib/python2.1/config -lboost_python -lpython2.
1 -o build/lib.cygwin_nt-4.0-1.3.2-i686-2.1/convert.dll
build/temp.cygwin_nt-4.0-1.3.2-i686-2.1/convert.o: In function
`_tfFRQ45boost6python6detailt21instance_value_holder2Z1AZQ45boost6python6det
ailt13held_instance1Z1ARC4Term_v':
/users/pbienst/tmp/boost_cvs/boost/python/detail/extension_class.hpp(.__mall
oc_alloc_template<0>::text$_S_oom_malloc(unsigned int)+0x1e): undefined
reference to `cerr'
...
The macro USE_DL_IMPORT appears, and now the fact that we use gcc for
linking bites us since it does not link in libstdc++. I'm sure this could
probably be resolved by including libstdc++ in setup.py, but that's not
really an out-of-the-box approach.
Kind regards,
Peter
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -