zim-wiki team mailing list archive
Mailing list archive
Re: Zim building problems
-- Regarding python27.dll, a comment on stackoverflow (https://stackoverflow.com/questions/25053761/location-of-python27-dll-from-python-itself) says On 64-bit Windows the 32-bit python27.dll is really in C:\Windows\sysWOW64. But if you try opening the C:\Windows\system32\python27.dll in a 32-bit process, it'll open just fine. If I'm not mistaken, WOW stands for Woodoo Of Windows. ;-)
-- Maybe a free tool like Dependency Walker (http://www.dependencywalker.com/) would be useful. Might need to use the application profiling feature. There's also a potentially useful FAQ.
-- I think you said a slightly earlier version of zim runs ok. Can you get a list of DLLs a program used, sorted by time of first access? If so, perhaps would be useful to compare the lists from the old and new versions of zim. The first significant difference might well be the DLL the new version isn't finding.
On Thursday, August 31, 2017, 3:42:12 PM PDT, mystyc <mystyc1@xxxxxxxxx> wrote:
In looking for the alleged offending dll file, I rebuilt and subsequently ran the rebuilt zim from within a sandbox program (sandboxie) while monitoring the resources accessed during that time. Attached, you will find these 2 log files, one with only the output resulting from python windows\build_ win32.py, and the other from Zim Desktop Wiki Portable.exe.
Actually, the build command uses "pyx2" (in place of "python"), a unique environmental variable that I use to invoke my 32-bit python-27 interpreter. I also have the 64-bit version of python-27, as well as both 32 and 64-bit versions of python-3, but each exists in its own directory accessing the appropriate python libraries and packages therein. The directory for the 32-bit 2.7 interpreter is "python27x32\", and the attached build-time log seems to confirm that the script accesses the dll files corresponding to the correct python version, but I cannot say the same for the windows system dll files. At one point, the build-time log records the script accessing the file (or image of) "c:\windows\system32\python27.dll," which I cannot seem to find.
As for the runtime log, most of the dll files are within the zim directory tree, except for a bunch of windows system dll files.
Is anyone else able to build this version of Zim on windows 7?
On Thu, Aug 31, 2017 at 1:57 PM, Loren Rosen <lorenrosen@xxxxxxxxx> wrote:
(This may appear as a top-level message rather than as a response, due to email client and launchpad problems.)
Don't know much about DLLs specifically, so let me ask a potentially dumb question. When does it try to load a DLL? Could it be that the difference seen is because one program tries to load libraries and the other doesn't get that far? I ask because, at least with the old C and Unix dynamic libraries, it would be quite easy to compile your program with no errors and yet have it fail to actually run.
Other things:Is there an easy way to tell where it's looking for libraries, and/or where it found them?In particular, could there be a 32- vs 64-bit problem?An example in wikipedia (in https://en.wikipedia.org/wiki/ Dynamic-link_library#Python) suggests you can directly try to load a DLL:
my_dll = ctypes.cdll.LoadLibrary(" Example.dll")
Looking at the Python docs, seems like ctypes.util.find_library( name) will return the path for the library. Also, perhaps ctypes.OleDL and ctypes.WinDLL will be useful. Maybe they have better error handling. (I think you'd use these instead of ctypes.cdll.)
Mailing list: https://launchpad.net/~zim- wiki
Post to : zim-wiki@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~zim- wiki
More help : https://help.launchpad.net/ ListHelp