Subject: RE: building Python extension modules - crash on import
From: "Peter Bienstman" <[email-masked]>
To: "Jason Tishler" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Tue, 7 Aug 2001 11:36:46 +0200

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