Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problems importing _sre w/VC7-compiled Python 2.1

1 view
Skip to first unread message

RoadRunner eNews

unread,
May 18, 2002, 2:54:18 PM5/18/02
to
I've successfully built Python 2.1 with VC7, but I'm having a problem using
the resulting binaries, namely _sre.pyd (and _d.pyd). Specifically, when I
attempt to 'import re', the result is a Traceback stating 'ImportError:
dynamic module does not define init function (init_sre)'. Everything works
fine under VC6, and ...\modules\_sre.c definitely contains init_sre(), so it
has to be something VC7 related.

Has anybody run into this problem? I'd appreciate it if somebody
in-the-know out there could build Python 2.1 with VC7 (you'll need to apply
Mark Hammond's largeint patch), run the interpreter from the command line,
attempt to import re and share the results. I'm no Python guru, so am at a
loss on how to continue at this point. Any help would be greatly
appreciated.

Thanks,
David Aldridge


Martin v. Loewis

unread,
May 18, 2002, 5:14:19 PM5/18/02
to
"RoadRunner eNews" <audb...@yahoo.com> writes:

> I'm no Python guru, so am at a loss on how to continue at this
> point.

I recommend to try CVS Python.

Regards,
Martin

John Machin

unread,
May 18, 2002, 8:17:12 PM5/18/02
to
"RoadRunner eNews" <audb...@yahoo.com> wrote in message news:<urxF8.92424$9F5.5...@typhoon.austin.rr.com>...

> I've successfully built Python 2.1 with VC7, but I'm having a problem using
> the resulting binaries, namely _sre.pyd (and _d.pyd). Specifically, when I
> attempt to 'import re', the result is a Traceback stating 'ImportError:
> dynamic module does not define init function (init_sre)'. Everything works
> fine under VC6, and ...\modules\_sre.c definitely contains init_sre(), so it
> has to be something VC7 related.
>

I'm not an MS VCn guru for any value of n. However, based on some
trips through "DLL hell" with other compilers, here are some ideas
that may help:

(1) Use the Dependency Walker or some other tool to examine the
_sre.pyd itself to see that the entry point init_sre is actually there
(and not _init_sre or something else), rather than relying on its
presence in the source. Then you will know whether the problem is in
the importer or the importee.

(2) If you haven't done so already, you should use the -v option when
running Python, to display the names of the actual full paths for
files that it is opening. However I can't recall whether you will get
the path printed before the ImportError.

HTH,
John

David Aldridge

unread,
May 18, 2002, 10:16:08 PM5/18/02
to
mar...@v.loewis.de (Martin v. Loewis) wrote in message news:<m3ptztw...@mira.informatik.hu-berlin.de>...


Following your suggestion, I tried using ActiveState's 2.1.3 tarball
(easier than a CVS checkout for me...). Sadly, I got the same
behavior. Anybody else have ideas?

(BTW, the 2.2.1 tarball also behaved the same. I need a 2.1x solution
though, as using 2.2 is out of the question for various reasons not
worth mentioning here...)

Thanks,
David

David Aldridge

unread,
May 19, 2002, 8:33:00 AM5/19/02
to
Sorry if this gets double posted -- RoadRunner puked on my sending
earlier, so it's straight-to-Google time!

Anyway, your suggestions were spot on (and so obvious that I should
slap myself...) Using dumpbin showed that all of the modules I
compiled contained *NO* exports. Adding an /EXPORT:<blah> setting to
the linker line "fixed" the problem, but that shouldn't be necessary,
as the appropriate functions are __declspec(dllexport). Bizarro...
*sigh* Guess it's time to spend a year figuring out how/why exports
are broken. Bah, Microsoft. Bah.

David

sjma...@lexicon.net (John Machin) wrote in message news:<c76ff6fc.02051...@posting.google.com>...

Robin Becker

unread,
May 19, 2002, 8:47:40 AM5/19/02
to
In article <597ee21d.02051...@posting.google.com>, David
Aldridge <dald...@austin.rr.com> writes

>Anyway, your suggestions were spot on (and so obvious that I should
>slap myself...) Using dumpbin showed that all of the modules I
>compiled contained *NO* exports. Adding an /EXPORT:<blah> setting to
>the linker line "fixed" the problem, but that shouldn't be necessary,
>as the appropriate functions are __declspec(dllexport). Bizarro...
>*sigh* Guess it's time to spend a year figuring out how/why exports
>are broken. Bah, Microsoft. Bah.
>
>David
Perhaps the pre-processor conditional code defining DL_EXPORT in
pyconfig.h broke for some reason. Perhaps one of the standard defines is
absent/different.
--
Robin Becker

David Aldridge

unread,
May 19, 2002, 9:26:01 AM5/19/02
to
After more investigation, turns out init_sre() was NOT
__declspec(dllexport)!

_sre.c #includes "Python.h"
"Python.h" #includes "config.h"

config.h, starting at line 120, has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

If I change it to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

Everything works just peachy. (Added the dllexport line if
USE_DL_IMPORT is defined).

Turns out since python/pythoncore is in a .DLL, the sre module wanted
to import its exports, and had USE_DL_IMPORT defined. However, since
DL_EXPORT was not defined in the USE_DL_IMPORT block, later on in
Python.h (after it's done preprocessing config.h), DL_EXPORT(RTYPE) is
simply defined as RTYPE. Oops -- no export of init_sre().

Thanks for the prod in the right direction ;-)
David

sjma...@lexicon.net (John Machin) wrote in message news:<c76ff6fc.02051...@posting.google.com>...

Andrew MacIntyre

unread,
May 20, 2002, 5:27:49 AM5/20/02
to
On 19 May 2002, David Aldridge wrote:

> After more investigation, turns out init_sre() was NOT
> __declspec(dllexport)!

I had been under the impression that sre was intended to always be built
into the Python core (ie not as a loadable extension module), which might
explain some of what you found.

--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: and...@bullseye.apana.org.au | Snail: PO Box 370
and...@pcug.org.au | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia

Robin Becker

unread,
May 20, 2002, 3:42:53 PM5/20/02
to
In article <mailman.1021922017...@python.org>, Andrew
MacIntyre <and...@bullseye.apana.org.au> writes

>On 19 May 2002, David Aldridge wrote:
>
>> After more investigation, turns out init_sre() was NOT
>> __declspec(dllexport)!
>
>I had been under the impression that sre was intended to always be built
>into the Python core (ie not as a loadable extension module), which might
>explain some of what you found.
>
well with Python 2.2.1 and win32 I certainly see _sre.pyd in the DLLs
directory.
--
Robin Becker

Fredrik Lundh

unread,
May 20, 2002, 4:09:10 PM5/20/02
to
Andrew MacIntyre wrote:
> On 19 May 2002, David Aldridge wrote:
>
> > After more investigation, turns out init_sre() was NOT
> > __declspec(dllexport)!
>
> I had been under the impression that sre was intended to always be built
> into the Python core (ie not as a loadable extension module), which might
> explain some of what you found.

SRE builds just fine as a DLL, and uses a DL_EXPORT statement
to make sure it exports the right stuff. this works perfectly fine
under VC5 and VC6.

looks like the DL_EXPORT stuff simply doesn't work under VC7.
someone should file a bug report (http://www.python.org/dev/).

</F>


David Aldridge

unread,
May 20, 2002, 8:20:38 PM5/20/02
to
I just submitted the bug. Will be interesting to see what the "correct" fix
is, if it's not the one I posted :)

Cheers,
David


"Fredrik Lundh" <fre...@pythonware.com> wrote in message
news:GJcG8.8159$p56.2...@newsb.telia.net...

0 new messages