Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Reply-To: <Peter DOT Bienstman AT rug DOT ac DOT be>
From: "Peter Bienstman" <Peter DOT Bienstman AT rug DOT ac DOT be>
To: "Jason Tishler" <jason AT tishler DOT net>
Cc: <nhv AT cape DOT com>, <cygwin AT cygwin DOT com>
Subject: RE: building Python extension modules - crash on import
Date: Tue, 7 Aug 2001 11:36:46 +0200
Message-ID: <001001c11f24$7a67a0e0$0454c19d@intec.rug.ac.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <20010806135153.N1888@dothill.com>

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