and so presumably was _SHIP ... therefore it appears that you might be
better off asking for help on the SWIG mailing list.
I will too.
c) Is there some way to find out which DLL and which procedure is
involved?
One would expect given the reported context (import _SHIP) that it has
found (somewhere!) a DLL called "_SHIP.pyd" and is looking in it
(unsuccessfully) for an entrypoint called "init_SHIP".
The usual suspect here would be the C (or C++) compiler messing with the
name of the entrypoint; possible messes include underscores at the front
and/or frame size at the end e.g. "_initfoo@12" instead of just "initfoo".
Possibly you are using a C[++] compiler that's not the one that SWIG
thinks you are using.
But exactly which DLL? Given your "interesting" sys.path, it might be an
idea to run python with the -v argument, so you can see where all your
imports are resolved.
I've not been able to find where sys.path finds its components and would
happily sort them out. It does not seem to be PYTHONPATH or PATH or
PYTHON_LIB.
I had to make Python as I wanted a debug build for Win32 (and hence
E:\Bill\Python-2.4.1\PCbuild\python24_d.zip on sys.path though why the zip I
have no idea). I have discovered the symbol __debug__ is True for debug
builds.
Once you have worked out which _SHIP.pyd is the cause, you can inspect it
and determine what entrypoint(s) it has.
HTH,
John
Dear John (and all)
That's a great help, really. A simple thing like reminding me of -v (give a
man a fish, etc) will help now and hereafter.
So, now we can see what Python is trying to do:
Python 2.4.1 (#65, May 24 2005, 11:31:45) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
# trying H:\Husky\HostPC\V1\SHIP\Debug\SHIP_d.pyd
# trying H:\Husky\HostPC\V1\SHIP\Debug\SHIP_d.dll
# trying H:\Husky\HostPC\V1\SHIP\Debug\SHIP.py
# H:\Husky\HostPC\V1\SHIP\Debug\SHIP.pyc matches
H:\Husky\HostPC\V1\SHIP\Debug\SHIP.py
import SHIP # precompiled from H:\Husky\HostPC\V1\SHIP\Debug\SHIP.pyc
# trying H:\Husky\HostPC\V1\SHIP\Debug\_SHIP_d.pyd
# clear[2] __name__
# clear[2] __file__
Traceback (most recent call last):
File "H:\Husky\HostPC\V1\SHIP\test1.py", line 15, in ?
import SHIP
File "H:\Husky\HostPC\V1\SHIP\Debug\SHIP.py", line 5, in ?
import _SHIP
ImportError: DLL load failed: The specified procedure could not be found.
# clear __builtin__._
It's still not clear what procedure could not be found (surely not
__file__?!). However, the output from "dumpbin /exports
H:\Husky\HostPC\V1\SHIP\Debug\_SHIP_d.pyd" is:
H:\Husky\HostPC\V1\SHIP\Debug>dumpbin /exports
H:\Husky\HostPC\V1\SHIP\Debug\_SHIP_d.pyd
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file H:\Husky\HostPC\V1\SHIP\Debug\_SHIP_d.pyd
File Type: DLL
Section contains the following exports for SHIP.pyd
0 characteristics
429D76E4 time date stamp Wed Jun 01 09:50:44 2005
0.00 version
1 ordinal base
1 number of functions
1 number of names
ordinal hint RVA name
1 0 00001096 init_SHIP
Summary
6000 .data
2000 .idata
3000 .rdata
2000 .reloc
1000 .rsrc
20000 .text
So _SHIP_d.pyd does export init_SHIP.
The odd thing there (to me) is the reference to "SHIP.pyd". Is that coming
from SHIP.def which has:
LIBRARY "SHIP"
The thing that is really bugging me is that this was all working before the
weekend :-(
I am also posting this to the SWIG mailing list as suggested.
TIA
Bill
