Re: [Zim-wiki] Zim building problems

2017-08-31 Thread mystyc 
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?

~Kevin


On Thu, Aug 31, 2017 at 1:57 PM, Loren Rosen  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:
>
> import ctypes
>
> 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~zim-wiki
> More help   : https://help.launchpad.net/ListHelp
>
>
(Drive) \Device\HarddiskVolume12
(Drive) \Device\HarddiskVolume2
(Drive) \Device\HarddiskVolume3
(Drive) \Device\HarddiskVolume4
(Drive) \Device\HarddiskVolume5
(Drive) \Device\HarddiskVolume6
(Drive) \Device\HarddiskVolume7
(Drive) \Device\HarddiskVolume8
Clsid   ---
File/Key---
Image   ---
Image   *:\ide+\python\python27x32\python.exe
Image   *:\program files (x86)\nsis\bin\makensis.exe
Image   *:\program files (x86)\nsis\makensis.exe
Image   c:\windows\system32\apphelp.dll
Image   c:\windows\system32\cryptsp.dll
Image   c:\windows\system32\dnsapi.dll
Image   c:\windows\system32\dwmapi.dll
Image   c:\windows\system32\imm32.dll
Image   c:\windows\system32\iphlpapi.dll
Image   c:\windows\system32\msimg32.dll
Image   c:\windows\system32\msvcp60.dll
Image   c:\windows\system32\propsys.dll
Image   c:\windows\system32\python27.dll
Image   c:\windows\system32\rsaenh.dll
Image   c:\windows\system32\uxtheme.dll
Image   c:\windows\system32\version.dll
Image   c:\windows\system32\winmm.dll
Image   c:\windows\system32\winnsi.dll
Image   c:\windows\system32\winspool.drv
Image   c:\windows\syswow64\advapi32.dll
Image   c:\windows\syswow64\cfgmgr32.dll
Image   c:\windows\syswow64\comdlg32.dll
Image   c:\windows\syswow64\crypt32.dll
Image   c:\windows\syswow64\cryptbase.dll
Image   c:\windows\syswow64\devobj.dll
Image   c:\windows\syswow64\gdi32.dll
Image   c:\windows\syswow64\imagehlp.dll
Image   c:\windows\syswow64\kernel32.dll
Image   c:\windows\syswow64\kernelbase.dll
Image   c:\windows\syswow64\lpk.dll
Image   c:\windows\syswow64\msasn1.dll
Image   c:\windows\syswow64\msctf.dll
Image   c:\windows\syswow64\msvcrt.dll
Image   c:\windows\syswow64\nsi.dll
Image   c:\windows\syswow64\ntdll.dll
Image   c:\windows\syswow64\ole32.dll
Image   c:\windows\syswow64\oleaut32.dll
Image   c:\windows\syswow64\psapi.dll
Image   c:\windows\syswow64\rpcrt4.dll
Image

Re: [Zim-wiki] Zim building problems

2017-08-31 Thread Loren Rosen 
(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:
import ctypes
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Re: [Zim-wiki] Zim building problems

2017-08-28 Thread mystyc 
Yeah.  I had successfully compiled an earlier build of 0.67 (might've been
0.67-RC2) into similar directories, and it had all the same dependencies,
except for the change where the full microsoft visual C++ 2008
redistribution package is now needed, instead of the just the libraries
in Microsoft.VC90.CRT.  I have the full redistribution package now, and it
is being used during the building process.

The windows/build_win32.py script runs successfully and without error all
the way through to the creation of the zim standalone and portable
executables, but zim won't run from them.  The non-debug executables don't
seem to do anything at all when I try to use them, even with any command
line options (like zim --help).  I am only about to get that debug output
using the zim debug executables.

My strange directory naming scheme is almost never an issue with anything
related to software development (tools, libraries, IDEs), that is except
for microsoft development programs like Visual Studio and microsoft SQL
server.  The irony of this is not lost on me.

So basically, I did not include any other error messages because there
aren't any.  I can't figure out what DLL file it might be trying to load
during runtime but not while building it.

~Kevin

On Mon, Aug 28, 2017 at 5:01 PM, Brendan Kidwell  wrote:

> Did you install all of the requirements listed in the Windows build readme?
> https://raw.githubusercontent.com/jaap-karssenberg/zim-
> desktop-wiki/master/windows/README-BUILD-win32.txt
>
> Silly question: do you think the folder name "MyCode.Source\Source.Upload"
> might have anything to do with it? Having periods in the name SHOULDN'T be
> a problem, but you never know with old broken systems like GTK2.
>
> I can't be sure from your debug log, so I'm just checking: Did you run
> windows/build_win32.py with the project root folder being the current
> working folder? Did that script display any errors?
>
> Brendan Kidwell
>
> On Sun, Aug 27, 2017, at 00:50, mystyc wrote:
>
> Is anyone else having trouble with trying to build Zim on Windows from the
> current 0.67 source on github?  I'm actually able to fully build the
> executables, but they won't run.
>
> Here's what I get for the debugger output when I try to run the zim
> executable:
>
> INFO: This is zim 0.67
> DEBUG: Python version is sys.version_info(major=2, minor=7, micro=13,
> releaselevel='final', serial=0)
> DEBUG: Platform is nt
> DEBUG: No bzr version-info found
> DEBUG: Running from a source dir: D:\MyCode.Source\Source.
> Upload\Zim\windows\build\ZimDesktopWiki
> DEBUG: Set XDG_DATA_HOME to D:\MyCode.Source\Source.
> Upload\Zim\windows\App\Data
> DEBUG: Set XDG_DATA_DIRS to [ Upload\Zim\windows\.local\share>]
> DEBUG: Set XDG_CONFIG_HOME to D:\MyCode.Source\Source.
> Upload\Zim\windows\App\Config
> DEBUG: Set XDG_CONFIG_DIRS to [ Upload\Zim\windows\.config>]
> DEBUG: Set XDG_CACHE_HOME to D:\MyCode.Source\Source.
> Upload\Zim\windows\App\Cache
> ERROR: Exception in main()
> Traceback (most recent call last):
>   File "zim\main\__init__.pyo", line 844, in main
>   File "zim\main\__init__.pyo", line 626, in run
>   File "zim\main\__init__.pyo", line 656, in _run_cmd
>   File "zim\main\__init__.pyo", line 663, in _run_main_loop
>   File "gtk\__init__.pyo", line 40, in 
>   File "gtk\_gtk.pyo", line 12, in 
>   File "gtk\_gtk.pyo", line 10, in __load
> ImportError: DLL load failed: The specified module could not be found.
>
>
>
> With respect to the error referenced for line 663 of
> zim\main\__init__.pyo, I can import gtk and gobject in IDLE without any
> issues.
>
> Thanks~
> ~Kevin
>
> *___*
> Mailing list: https://launchpad.net/~zim-wiki
> Post to : zim-wiki@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~zim-wiki
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~zim-wiki
> Post to : zim-wiki@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~zim-wiki
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp

Re: [Zim-wiki] Zim building problems

2017-08-28 Thread Brendan Kidwell 
Did you install all of the requirements listed in the Windows
build 
readme?https://raw.githubusercontent.com/jaap-karssenberg/zim-desktop-wiki/master/windows/README-BUILD-win32.txt
Silly question: do you think the folder name
"MyCode.Source\Source.Upload" might have anything to do with it? Having
periods in the name SHOULDN'T be a problem, but you never know with old
broken systems like GTK2.
I can't be sure from your debug log, so I'm just checking: Did you run
windows/build_win32.py with the project root folder being the current
working folder? Did that script display any errors?
Brendan Kidwell

On Sun, Aug 27, 2017, at 00:50, mystyc wrote:
> Is anyone else having trouble with trying to build Zim on Windows from
> the current 0.67 source on github?  I'm actually able to fully build
> the executables, but they won't run.> 
> Here's what I get for the debugger output when I try to run the zim
> executable:>> INFO: This is zim 0.67
>> DEBUG: Python version is sys.version_info(major=2, minor=7, micro=13,
>> releaselevel='final', serial=0)>> DEBUG: Platform is nt
>> DEBUG: No bzr version-info found
>> DEBUG: Running from a source dir:
>> D:\MyCode.Source\Source.Upload\Zim\windows\build\ZimDesktopWiki>> DEBUG: Set 
>> XDG_DATA_HOME to
>> D:\MyCode.Source\Source.Upload\Zim\windows\App\Data>> DEBUG: Set 
>> XDG_DATA_DIRS to [> D:\MyCode.Source\Source.Upload\Zim\windows\.local\share>]>> DEBUG: Set 
>> XDG_CONFIG_HOME to
>> D:\MyCode.Source\Source.Upload\Zim\windows\App\Config>> DEBUG: Set 
>> XDG_CONFIG_DIRS to [> D:\MyCode.Source\Source.Upload\Zim\windows\.config>]>> DEBUG: Set 
>> XDG_CACHE_HOME to
>> D:\MyCode.Source\Source.Upload\Zim\windows\App\Cache>> ERROR: Exception in 
>> main()
>> Traceback (most recent call last):
>>   File "zim\main\__init__.pyo", line 844, in main
>>   File "zim\main\__init__.pyo", line 626, in run
>>   File "zim\main\__init__.pyo", line 656, in _run_cmd
>>   File "zim\main\__init__.pyo", line 663, in _run_main_loop
>>   File "gtk\__init__.pyo", line 40, in 
>>   File "gtk\_gtk.pyo", line 12, in 
>>   File "gtk\_gtk.pyo", line 10, in __load
>> ImportError: DLL load failed: The specified module could not
>> be found.>> 
> 
> 
> With respect to the error referenced for line 663 of
> zim\main\__init__.pyo, I can import gtk and gobject in IDLE without
> any issues.> 
> Thanks~
> ~Kevin
> 
> _
> Mailing list: https://launchpad.net/~zim-wiki
> Post to : zim-wiki@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~zim-wiki
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~zim-wiki
Post to : zim-wiki@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zim-wiki
More help   : https://help.launchpad.net/ListHelp