DLL load failed: The specified procedure could not be found
Bill at SynectixLtd.com
Wed Jun 1 11:40:40 CEST 2005
"John Machin" <sjmachin at lexicon.net> wrote in message
news:429cf3cf$1 at news.eftel.com...
>> 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
> 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 at 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
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
> Once you have worked out which _SHIP.pyd is the cause, you can inspect it
> and determine what entrypoint(s) it has.
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
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
import SHIP # precompiled from H:\Husky\HostPC\V1\SHIP\Debug\SHIP.pyc
# trying H:\Husky\HostPC\V1\SHIP\Debug\_SHIP_d.pyd
# clear __name__
# clear __file__
Traceback (most recent call last):
File "H:\Husky\HostPC\V1\SHIP\test1.py", line 15, in ?
File "H:\Husky\HostPC\V1\SHIP\Debug\SHIP.py", line 5, in ?
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
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
429D76E4 time date stamp Wed Jun 01 09:50:44 2005
1 ordinal base
1 number of functions
1 number of names
ordinal hint RVA name
1 0 00001096 init_SHIP
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:
The thing that is really bugging me is that this was all working before the
I am also posting this to the SWIG mailing list as suggested.
More information about the Python-list