Runs on Windows 7, but fails on XP
Michael Durian
bluetooth not supported: DLL load failed: The specified procedure could not be found.
File "<string>", line 220, in <module>
File "<string>", line 12, in __init__
File "Z:\Desktop\src\ISC\btapps\build\pyi.win32\version\outPYZ1.pyz/lib.bt_gateway", line 282, in BtGatewayFactor
NameError: global name 'BtGatewayBlueZ' is not defined
BtGatewayBlueZ is not defined because its definition is conditional on importing the bluetooth module:
try:
import bluetooth
except Exception, e:
print e
BLUEZ_SUPPORTED = False
else:
BLUEZ_SUPPORTED = True
I don't know where to begin to diagnose which specified procedure is missing in the bluetooth DLL or how to fix things so it will run under XP. Can anyone offer some advice?
mike
Michael Durian
Raoul Snyman
On 19 February 2011 17:13, Michael Durian <dur...@boogie.com> wrote:
> BtGatewayBlueZ is not defined because its definition is conditional on importing
> the bluetooth module:
> try:
> import bluetooth
> except Exception, e:
> print e
> BLUEZ_SUPPORTED = False
> else:
> BLUEZ_SUPPORTED = True
>
> I don't know where to begin to diagnose which specified procedure is missing
> in the bluetooth DLL or how to fix things so it will run under XP. Can anyone
> offer some advice?
It looks like you probably need to create a hook file. See
http://www.pyinstaller.org/export/latest/trunk/doc/Manual.html?format=raw#listing-hidden-imports
for how to do this.
--
Raoul Snyman
B.Tech Information Technology (Software Engineering)
E-Mail: raoul....@gmail.com
Web: http://www.saturnlaboratories.co.za/
Blog: http://blog.saturnlaboratories.co.za/
Mobile: 082 550 3754
Registered Linux User #333298 (http://counter.li.org)
Michael Durian
If I compare the verbose imports output when running under Windows 7 to the output under XP, I see where 7 succeeds and XP fails:
import bluetooth._msbt # dynamically loaded from C:/Users/ADMINI~1/AppData/Local/Temp/_MEI28642\bluetooth._msbt.pyd
XP show the following in the same place in the output:
DLL load failed: The specified procedure could not be found.
I'm at a loss as to what hook I need to create.
If I look at the warn output, I see a couple messages regarding non-conditional top-level imports. The document Raoul sited says those are probably hard errors. Here are the bluetooth-related messages:
W: no module named fcntl (top-level import by bluetooth.bluez)
W: no module named _bluetooth (top-level import by bluetooth.bluez)
W: no module named fcntl (top-level import by bluetooth)
W: no module named _bluetooth (top-level import by bluetooth)
W: top-level exec statement detected at line 0 - bluetooth.bluez (C:\Python26\lib\site-packages\bluetooth\bluez.pyc)
W: delayed exec statement detected at line 0 - bluetooth.bluez (C:\Python26\lib\site-packages\bluetooth\bluez.pyc)
I tried to address the fcntl and _bluetooth warnings by creating hook-bluetooth.py in the hooks directory containing the following line:
hiddenimports = ['fcntl', '_bluetooth']
That doesn't seem to help.
When I run Build.py to create the exe, I do get an error in the output:
E: lib not found: wbtapi.dll dependency of C:\Python26\lib\site-packages\bluetooth\_widcomm.pyd
I cannot find wbtapi.dll anywhere on the Windows 7 or Windows XP systems.
I'm not sure what to do next.
mike
> --
> You received this message because you are subscribed to the Google Groups "PyInstaller" group.
> To post to this group, send email to pyins...@googlegroups.com.
> To unsubscribe from this group, send email to pyinstaller...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pyinstaller?hl=en.
>
>
>
> !DSPAM:4d61f80411109646414669!
Raoul Snyman
On 22 February 2011 20:29, Michael Durian <dur...@boogie.com> wrote:
> I tried to address the fcntl and _bluetooth warnings by creating hook-bluetooth.py in the hooks directory containing the following line:
> hiddenimports = ['fcntl', '_bluetooth']
>
> That doesn't seem to help.
You need to run Configure.py again after adding the hook file, have you done so?
Michael Durian
On Feb 22, 2011, at 10:43 PM, Raoul Snyman wrote:
> Hi Michael,
>
> On 22 February 2011 20:29, Michael Durian <dur...@boogie.com> wrote:
>> I tried to address the fcntl and _bluetooth warnings by creating hook-bluetooth.py in the hooks directory containing the following line:
>> hiddenimports = ['fcntl', '_bluetooth']
>>
>> That doesn't seem to help.
>
> You need to run Configure.py again after adding the hook file, have you done so?
No, I did not run Configure.py. I missed that.
Now that I have run it, I don't see any difference. The behavior is the same as before. Do I need to do anything else besides adding a file called hook-bluetooth.py containing the hiddenimports line and running Configure.py? When I run Configure.py, the output doesn't show anything about the bluetooth module.
I've now run Configure.py twice. After the first time, I could have sworn I found bluetooth references in a logdict file but they aren't there now.
mike
Raoul Snyman
> Now that I have run it, I don't see any difference. The behavior is the same as before.
> Do I need to do anything else besides adding a file called hook-bluetooth.py containing
> the hiddenimports line and running Configure.py? When I run Configure.py, the output
> doesn't show anything about the bluetooth module.
Make sure you have the correct information in that hook file. For
instance, you said that "import bluetooth" is a conditional import,
but your import file doesn't contain that. Try creating a hook file
for that hidden import?
Michael Durian
> On 23 February 2011 17:28, Michael Durian <dur...@boogie.com> wrote:
>> Now that I have run it, I don't see any difference. The behavior is the same as before.
>> Do I need to do anything else besides adding a file called hook-bluetooth.py containing
>> the hiddenimports line and running Configure.py? When I run Configure.py, the output
>> doesn't show anything about the bluetooth module.
>
> Make sure you have the correct information in that hook file. For
> instance, you said that "import bluetooth" is a conditional import,
> but your import file doesn't contain that. Try creating a hook file
> for that hidden import?
I'm not quite sure what you mean. "import bluetooth" is only conditional in so far as it isn't used on OS X. It is always imported under all Windows flavors.
Hartmut Goebel
> Make sure you have the correct information in that hook file. For
> instance, you said that "import bluetooth" is a conditional import,
> but your import file doesn't contain that. Try creating a hook file
> for that hidden import?
a problem of a hidden import.
I suggest to look into the build .exe using ArchiveViewer.py to verify
the required files are in. Since pybluez tries to load some compiled
extensions, perhaps these fail to load. Maybe some additional required
dll is missing or can not be loaded.
BTW: This import is conditional, but not hidden. PyInstaller handles
conditional imports quite fine, since it looks for *all* import
statements in all Python modules it can get it's hands on.
--
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP
Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de
Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult mit Mitglied bei http://www.7-it.de
Michael Durian
> Am 24.02.2011 14:28, schrieb Raoul Snyman:
>> Make sure you have the correct information in that hook file. For
>> instance, you said that "import bluetooth" is a conditional import,
>> but your import file doesn't contain that. Try creating a hook file
>> for that hidden import?
> AS the OP wrote, the program runs fine on Windows 7. So it should not be
> a problem of a hidden import.
>
> I suggest to look into the build .exe using ArchiveViewer.py to verify
> the required files are in. Since pybluez tries to load some compiled
> extensions, perhaps these fail to load. Maybe some additional required
> dll is missing or can not be loaded.
I've gone ahead and installed python and the dependancies I need under XP
so I can run PyInstaller on it. I just used ArchiveViewer.py to compare the
.exe generated under XP to the one generated under Windows 7. Aside from
some offset differences starting with irprops.cpl, the XP build does include some
files not found in the Windows 7 build. Specifically,
DEVMGR.DLL
SETUPAPI.dll
WMI.dll
Do I need to add those to a hook file as a hiddenimport? Does anyone know
why they weren't picked up when PyInstaller ran under Windows 7?
mike
Florian Höch
Am 24.02.2011 16:57, schrieb Michael Durian:
> I've gone ahead and installed python and the dependancies I need under XP
> so I can run PyInstaller on it. I just used ArchiveViewer.py to compare the
> .exe generated under XP to the one generated under Windows 7. Aside from
> some offset differences starting with irprops.cpl, the XP build does include some
> files not found in the Windows 7 build. Specifically,
> DEVMGR.DLL
> SETUPAPI.dll
> WMI.dll
Those look a lot like system DLLs to me. It could actually be necessary
to add those to PyInstaller's exclude list. Does the executable
generated in XP run in Windows 7?
> Do I need to add those to a hook file as a hiddenimport? Does anyone know
> why they weren't picked up when PyInstaller ran under Windows 7?
Under Windows 7, a lot of the system functionality has been moved to
different DLLs.
Regards
--
Florian Höch
Michael Durian
> Hi,
>
> Am 24.02.2011 16:57, schrieb Michael Durian:
>> I've gone ahead and installed python and the dependancies I need under XP
>> so I can run PyInstaller on it. I just used ArchiveViewer.py to compare the
>> .exe generated under XP to the one generated under Windows 7. Aside from
>> some offset differences starting with irprops.cpl, the XP build does include some
>> files not found in the Windows 7 build. Specifically,
>> DEVMGR.DLL
>> SETUPAPI.dll
>> WMI.dll
>
> Those look a lot like system DLLs to me. It could actually be necessary to add those to PyInstaller's exclude list. Does the executable generated in XP run in Windows 7?
Yes, it does.
If those system DLLs are present in the XP build, which runs on XP and W7, how would adding them to an exclude list allow a build on W7 to run on XP? Does it tell XP, "Hey, you think you need these, but really you don't. Get on with things already."
What do I need to do to test with those files on the exclude list?
mike
Michael Durian
> Am 24.02.2011 19:01, schrieb Michael Durian:
>> On Feb 24, 2011, at 10:34 AM, Florian Höch wrote:
>>
>>> Hi,
>>>
>>> Am 24.02.2011 16:57, schrieb Michael Durian:
>>>> I've gone ahead and installed python and the dependancies I need
>>>> under XP so I can run PyInstaller on it. I just used
>>>> ArchiveViewer.py to compare the .exe generated under XP to the
>>>> one generated under Windows 7. Aside from some offset
>>>> differences starting with irprops.cpl, the XP build does include
>>>> some files not found in the Windows 7 build. Specifically,
>>>> DEVMGR.DLL SETUPAPI.dll WMI.dll
>>>
>>> Those look a lot like system DLLs to me. It could actually be
>>> necessary to add those to PyInstaller's exclude list. Does the
>>> executable generated in XP run in Windows 7?
>>
>> Yes, it does.
>>
>> If those system DLLs are present in the XP build, which runs on XP
>> and W7, how would adding them to an exclude list allow a build on W7
>> to run on XP?
>
> No, the other way around. If the XP build would fail on W7, then adding those DLLs to the exclude list may have helped
What do I need to do to get them included in a W7 build? I tried adding them to hiddenimports, but that didn't work. How do you specify a list of additional DLLs that need to be included in the build?
mike
Florian Höch
Do they even exist on W7? You could do a search in Windows\system32.
Another possibility could be that PyBluez actually installs different
files with different dependencies on W7 and XP. This would not be easy
to fix I think.
Regards
--
Florian Höch
Florian Höch
>
>> Hi,
>>
>> Am 24.02.2011 16:57, schrieb Michael Durian:
>>> I've gone ahead and installed python and the dependancies I need
>>> under XP so I can run PyInstaller on it. I just used
>>> ArchiveViewer.py to compare the .exe generated under XP to the
>>> one generated under Windows 7. Aside from some offset
>>> differences starting with irprops.cpl, the XP build does include
>>> some files not found in the Windows 7 build. Specifically,
>>> DEVMGR.DLL SETUPAPI.dll WMI.dll
>>
>> Those look a lot like system DLLs to me. It could actually be
>> necessary to add those to PyInstaller's exclude list. Does the
>> executable generated in XP run in Windows 7?
>
> Yes, it does.
>
> If those system DLLs are present in the XP build, which runs on XP
> and W7, how would adding them to an exclude list allow a build on W7
> to run on XP?
No, the other way around. If the XP build would fail on W7, then adding
those DLLs to the exclude list may have helped.
> Does it tell XP, "Hey, you think you need these, but
> really you don't. Get on with things already."
>
> What do I need to do to test with those files on the exclude list?
>
> mike
--
Florian Höch
Michael Durian
Yes those files exist on W7. I just don't know how to force W7 to included them when it doesn't need them itself. Since the ArchiveViewer output is otherwise the same, I don't think PyBluez installs differently under different versions of Windows.
mike
Michael Durian
> Am 24.02.2011 20:07, schrieb Michael Durian:
>> DEVMGR.DLL SETUPAPI.dll WMI.dll
>
> Ok, I just downloaded PyBluez-0.18.win32-py2.6.exe, and none of the ByBluez pyds depends on any of those files (checked using pyinstaller's bindepend.py). So I think that they are unrelated to the problem.
Interesting. Were you able to verify what I'm seeing? Namely, that an executable built under W7 doesn't run under XP?
In case it helps, I'm attaching the output from ArchiverViewer from both XP and W7. Aside from those additional DLL's, the only other difference I noticed was a size difference for inrprops.cpl.
mike
Florian Höch
> DEVMGR.DLL SETUPAPI.dll WMI.dll
Ok, I just downloaded PyBluez-0.18.win32-py2.6.exe, and none of the
ByBluez pyds depends on any of those files (checked using pyinstaller's
bindepend.py). So I think that they are unrelated to the problem.
Regards
--
Florian Höch
Florian Höch
> Interesting. Were you able to verify what I'm seeing? Namely, that
> an executable built under W7 doesn't run under XP?
Yes.
> In case it helps, I'm attaching the output from ArchiverViewer from
> both XP and W7. Aside from those additional DLL's, the only other
> difference I noticed was a size difference for inrprops.cpl.
That was helpful indeed. The system file called 'irprops.cpl' is what
introduces the three additional files present in the XP build (it
doesn't have those dependencies under W7), but it's only a side effect.
That file itself is the problem and needs to be excluded. Edit
bindepend.py and add the following line somewhere in the 'excludes'
dictionary:
'IRPROPS.CPL':1,
Then delete your build directory (important) and re-build.
Regards
--
Florian Höch
Michael Durian
Thank you. I can confirm that that fixed the problem for me.
mike
Martin Zibricky
Michael Durian píše v Čt 24. 02. 2011 v 14:18 -0700:
Florian Höch
> Florian, are you going to commit this change?
Yes, I committed it to trunk right now.
Regards
--
Florian Höch
Florian Höch
the current exclude blacklist to a whitelist approach (atleast for
Windows), where everything from \Windows is excluded by default, and
only some whitelisted stuff is included (e.g. pythonXX.dll,
pythoncomXX.dll)?
Regards
--
Florian Höch
Hartmut Goebel
IMHO this would ease debugging: a) If a dll is not on the whitelist it
will not be included and the .exe will not work at all. b) Finding out
there is a dll missing should be easier than finding out there are to
many dlls. c) Since application should not install dlls into \windows
for quite some ears now, this should not be a problem.
Florian Höch
> +1
>
> IMHO this would ease debugging: a) If a dll is not on the whitelist it
> will not be included and the .exe will not work at all. b) Finding out
> there is a dll missing should be easier than finding out there are to
> many dlls. c) Since application should not install dlls into \windows
> for quite some ears now, this should not be a problem.
Yes, my thoughts exactly. I've written a small patch for bindepend.py
which implements this change as a combined blacklist/whitelist approach.
Bascically the current 'excludes' blacklist is kept but with all the
explicit Windows DLLs removed, and instead the current Windows directory
inserted. Then, a whitelist (I labeled it 'includes') is used to
override certain stuff that would otherwise be excluded (on Windows,
this means currently pythonNN.dll, pythoncomNN.dll and
pywintypesNN.dll). I've run the buildtests and all seems to work as
intended so far. How should I proceed further? Would it be OK to commit
to trunk?
Regards
--
Florian Höch
Hartmut Goebel
> pythoncomNN.dll and pywintypesNN.dll). I've run the buildtests and all
> seems to work as intended so far. How should I proceed further? Would
> it be OK to commit to trunk?
Florian Höch
> Am 28.02.2011 17:49, schrieb Florian Höch:
>> pythoncomNN.dll and pywintypesNN.dll). I've run the buildtests and all
>> seems to work as intended so far. How should I proceed further? Would
>> it be OK to commit to trunk?
> Yes, please. It's the easiest way to make others test it :-)
Done as r1358 :)
Regards
--
Florian Höch