"John Machin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> a) What "specified procedure "
>> b) SHIP was made by SWIG
>
> 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. "[EMAIL PROTECTED]" 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
--
http://mail.python.org/mailman/listinfo/python-list
