Title wxPython not working (waiting for upstream)
Priority bug Status deferred
Superseder Nosy List bosmart, kayhayen
Assigned To bosmart Keywords

Created on 2014-07-11.19:06:18 by bosmart, last changed by bosmart.

msg937 (view) Author: bosmart Date: 2015-01-07.07:23:49
Perfect, will give it a go when the patch is merged. Thanks!
msg936 (view) Author: kayhayen Date: 2015-01-06.22:58:02
I created a patch, and submitted it to wxpython, this will hopefully get accepted, 
like they did with my previous patch:

With that patch, wxpython should have no issues anymore.
msg931 (view) Author: kayhayen Date: 2015-01-05.19:20:45
This is not limited to Windows, and not to standalone. Compiled functions crash 
when used as callbacks on all platforms and for mere compiled modules.
msg930 (view) Author: kayhayen Date: 2015-01-05.19:19:11
Turns out, that my patch is no longer complete. The wxPython will need more 
patches. It accesses compiled method objects as if they were non compiled method 
objects, segfaulting therefore.
msg920 (view) Author: kayhayen Date: 2015-01-05.00:05:27
I found out that wxPython 2.8 does not contain my patch, and therefore does not 
work at all. The crash it gives on Windows is therefore uninteresting.

Seems you were using 3.0, and that has the patch. That however segfaults on my 
Debian with pure Python already. Need to check out Windows.
msg837 (view) Author: bosmart Date: 2014-11-16.21:56:06
Yes :)
msg836 (view) Author: kayhayen Date: 2014-11-16.21:06:23
When you say "it", you mean the created binary, after being compiled without 
error message?

msg835 (view) Author: bosmart Date: 2014-11-15.08:52:33
I have tried it yesterday again and it still crashes, w/o any useful message...
msg786 (view) Author: kayhayen Date: 2014-08-28.06:59:26
Oh, and if you could run it yourself with latest Nuitka, it would also be great, 
for the resolution of the DLL collision. It now outputs precise information when 
that happens.
msg785 (view) Author: kayhayen Date: 2014-08-28.06:57:27
So, with the technical limits out of the way, just to summarize this.

The wxPython is still not working, and it's not about standalone mode at all, at least not in an example I 
was findings.

Unfortunately, I didn't yet manage to get a debugger to properly work. Those I have use Python embedded 
themselves, and cannot debug Nuitka compiled binaries, or if compiled without Python, they are probably too 

However, Matic provided "" which crashes with --recurse-all already, i.e. acceleration. And 
with "--trace", my cheap poor mans tracing of Python to stdout, I am getting the function that crashes, 
which needs further investigation:

    def _BootstrapApp(*args, **kwargs):

        For internal use only
        return _core_.PyApp__BootstrapApp(*args, **kwargs)

So, I suspect this is a DLL and does something special, e.g. importing a hidden dependency without any 
error checking. We will have to check wx source code to know. 

BTW: Also the issue is Windows only, on Linux nothing of that kind is happening apparently.

msg752 (view) Author: kayhayen Date: 2014-08-11.08:07:00
The new release adds something for this.

BTW: VS 2013 is now "required" even, you need not run any special cmd script 

In case of DLL collisions, outputs will be made that will help me recognize what 
to do. Please submit the final error message. Let me know what it is.
msg731 (view) Author: kayhayen Date: 2014-07-21.21:35:16
Just saw this, in Scons 2.3.2 changelog:

-- Support for Visual Studio 12.0Exp and 2013

So that explains, why you have to set the environment manually. I am going to 
update the inline copy of Scons that Nuitka has, then that issue should be a 
thing of the past too.

I was using the Express version, the only free download so far. Maybe later, 
when .NET SDK gets an update or so, the real compilers will come to me too. You 
are welcome to compile with --debug and report warnings, should MSVC 2013 give 
new ones.
msg729 (view) Author: bosmart Date: 2014-07-20.13:37:10
I'm running VS2013 on Windows 7 x64. Anyway, looking forward to further developments :)
msg728 (view) Author: kayhayen Date: 2014-07-20.10:38:16
I see, I believe I am using 2012 (.NET 4.5 SDK), cannot use 2013, because it is 
Windows 8 only. However, Matic has the same thing on 2010 at least.

The fact it is not automatically recognized will be addressed with an update of 
the embedded Scons to 2.3.2 (use of embedded scons is enfored in Nuitka on 

On the bug itself, I will add traces to depends.exe, to give a more detailed 
information, what depends on what. Maybe that enlightens us when compared.

msg727 (view) Author: bosmart Date: 2014-07-18.18:21:17
I'm using the 64-bit compiler which comes with Visual Studio 2013.
msg726 (view) Author: kayhayen Date: 2014-07-18.17:51:39
Hm, strange, I thought that Scons will then use that to detect installed MSVC 
versions, but I need to recheck that obviously.

I am getting the suspect, that it is an issue, that you are not using the MSVC 
version used to compile CPython. So far, I never had an issue with it, but that 
would explain your crash. I am going to check it out. Do you have download link 
or something?

msg725 (view) Author: bosmart Date: 2014-07-18.16:42:21
aha! I do already have pywin32 installed... Anyway, I went for option b), it builds but 
still crashes on execution... There must be something about my setup then?
msg724 (view) Author: kayhayen Date: 2014-07-18.08:09:00
I made a hotfix this morning that corrects the relatively minor issue. It's due to using --show-
scons, when not finding a supported compiler. The trace was put too early. Making hotfixes has 
become automatic enough to do this without effort on my side.

Next it will tell you:

Error, cannot locate suitable C++ compiler. You have the following options:

a) If a suitable Visual Studio version is installed, it not located,
   automatically unless you install pywin32 for the Python installation
   below "%s".

b) To make it find Visual Studio execute from Start Menu the 'Visual Studio
   Command Prompt' or "vcvarsall.bat". That will add Visual Studio to the

b) Install MinGW to 'C:\\MinGW' then it is automatically picked up.

Don't follow the second option "b" (fixing the typo in next release). Use either
what you did previously, or install pywin32, which is seemingly required for Scons
to be able to find MSVC compilers.

On an important side note, I got MinGW64 to work with basic tests. I am hoping to
make it supported for standalone too. That might have a positive impact on the
compilation times, since gcc scales better than MSVC apparently. The real change,
to stop using C++ classes for local variables is also in sight, but probably will
take a few releases to land.

Anyway, please try it out, I think that it ought to work. And if you install new
stuff, can you check, for when the MSVC DLL appears first in the Python folder,
that would be great help. I am checking with Matic, if he has that DLL too, as he
seems to encounter the same issue.

Should that manifest as normal, a workaround of some sorts is probably needed. To
put the DLL there, is likely a bug of some installer. One would need to check,
which part of depends.exe picks it up, and for what.

msg723 (view) Author: bosmart Date: 2014-07-18.05:18:19
On a fresh install of everything I am now getting something new:

Scons command: c:\Python27\python.exe c:\Python27\Lib\site-packages\nuitka\build\inline_copy\bin\ -f 
c:\Python27\Lib\site-packages\nuitka\build\SingleExe.scons --jobs 3 --w
arn=no-deprecated --no-site-dir --debug=explain show_scons=true python_version=2.7 unstriped_mode=false 
icon_path=icon.ico full_compat=false debug_mode=false target_arch=x86_64 opt
imize_mode=true source_dir=C:\temp\dist-nuitka\ standalone_mode=true name=wxTest python_debug=false 
frozen_modules=689 python_prefix=c:\Python27 module_count=26 result_
name=C:\temp\dist-nuitka\wxTest.dist\wxTest nuitka_src=c:\Python27\Lib\site-packages\nuitka\build 
module_mode=false experimental=false
scons: Reading SConscript files ...
Scons compiler: UsingAttributeError: 'NoneType' object has no attribute 'startswith':
  File "C:\Python27\Lib\site-packages\nuitka\build\SingleExe.scons", line 392:
    print getExecutablePath( env[ "CXX" ], initial = False )
  File "C:\Python27\Lib\site-packages\nuitka\build\SingleExe.scons", line 156:
    if filename.startswith( "$" ):
msg722 (view) Author: bosmart Date: 2014-07-17.08:48:10
Yeah, it does take a while to compile even on a quite powerful machine; cl runs in multithreaded mode 
while Nuitka seems to be using a single.

Anyway, I have compiled without setting MSVC environment and after removing the DLL from the CPython 
install. It now builds without errors but it still crashes when run, without reporting any 

I will now try to setup the whole build environment from scratch and see how it goes.
msg721 (view) Author: kayhayen Date: 2014-07-17.06:39:39
Oh, and for the record, I now get why the traces to not show a duplicate. Well yes, 
of course, it's only done after successfully checking for duplicates, so this 

I also developed the suspect, that filenames as they come from depends.exe, which are 
added to the set, do not have "os.path.normcase" applied, that could be a source of 
problems too. So I will add "os.path.abspath" and it too, just in case. But thinking 
of it, that would be covered by "filecmp" not saying they are different, and silently 
skipping it. That wouldn't lead to different copies.

msg720 (view) Author: kayhayen Date: 2014-07-17.06:24:53
I tried to reproduce it, with a minimal example "import wx", but that didn't do 
the trick. BTW: It's a shame in terms of compilation times, with it, we really 
have some remaining problems.

Anyway, the resulting binary ran without issue. However, in the meantime, while 
trying to get the wx test suite to run, on the mailing list, Matic also reported 
the issue, and delivered the wx test suite to me, which ought to show the 

As this is going to compile forever (even Nuitka itself seems to take 
considerable time), it will take time.

The multiple versions of MSVC come from a "side by side" mechanism.

What sprung into my eye, from your screenshot is the "MSVCR90.dll" that lives in 
the Python installation. There is no such thing in my install. I am almost sure 
it ought to not be there, but maybe some installer put it there.

Since my test program is as simple as yours (the calls to use wx classes do not 
count for linking), may I ask you to do two things:

a) Compile without setting MSVC environment. Not needed for Nuitka, as its Scons 
will find the compiler itself. Doesn't it?

b) Move the DLL from the CPython install temporarily away, then compile again, 
it's likely to work.

msg719 (view) Author: bosmart Date: 2014-07-15.08:43:09
It seems I do have quite a few copies of this file...
msg718 (view) Author: kayhayen Date: 2014-07-15.07:29:45

starting the exe is not useful, as creating the ".dist" folder aborted. The 
conflicting DLLs is an error exit from in between. It will stop copying DLLs to 
there, once it first encountered the conflict.

I will try and reproduce it, once I have a Windows session again, the 
interesting thing, is how it comes to believe that there is already a 
MSVCR90.DLL, and where the two distinct ones are coming from.

Last time I tried, I got frustrated with the difficulties of installing GTK, Qt, 
and wx on Windows. Which is why I would prefer if this somehow resolves without 

You could try and trace nuitka.freezer.Standalone, before it outputs the error, 
and if it want to give it a try, you can make it not error exit out. But it 
would be wiser to understand which copies of the DLLs conflict, and to make a 
decision based on that.

I hope to get to this during the week, but I cannot promise.
msg717 (view) Author: bosmart Date: 2014-07-15.07:21:10
Ok, so I get the same behaviour with a very simple wxPython app:

import wx
app = wx.App(redirect=True)
top = wx.Frame(None, title="Hello World", size=(300,200))

It first says "Error, conflicting DLLs for 'MSVCR90.DLL'."

Then when launching the app, it says:
  File "", line 1, in <module>
  File "c:\Python27\lib\site-packages\wx-3.0-msw\wx\", line 45, in wx
    from wx._core import *
  File "c:\Python27\lib\site-packages\wx-3.0-msw\wx\", line 4, in _core
    import _core_
ImportError: LoadLibraryEx 'c:\Temp\dist-nuitka\wxTest.dist\wx\_core_.pyd' failed

Finally, after copying all wx*.dll files into the .dist/wx folder it just crashes without any warning.

These are the commands I'm using to build the exe:
call "c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\vcvars64.bat"
call c:\Python27\Scripts\nuitka --standalone --icon=icon.ico --output-dir=C:\temp\dist-nuitka --remove-output 
--improved --show-modules --show-scons --show-progress

Windows 7 x64, Python 2.7.8 x64, wxPython 3.0.0 (Windows binary downloaded from
msg716 (view) Author: bosmart Date: 2014-07-15.06:32:09
So, how can I help troubleshoot the problem?
msg715 (view) Author: bosmart Date: 2014-07-13.15:26:49
Nope, I'm getting exactly the same error even if the target directory is empty.
msg714 (view) Author: kayhayen Date: 2014-07-13.11:35:17
Hello Bosmart,

scons: done building targets.
> Nuitka:INFO:Included used shared library 'c:\windows\system32\GPSVC.DLL'.
> Nuitka:INFO:Included used shared library
> 'c:\windows\system32\PYTHON27.DLL'.
> Nuitka:INFO:Included used shared library
> 'c:\python27\lib\site-packages\wx-3.0-
> msw\wx\WXMSW30U_HTML_VC90_X64.DLL'.
> Nuitka:INFO:Included used shared library 'c:\windows\system32\WSOCK32.DLL'.
> Nuitka:INFO:Included used shared library 'c:\python27\MSVCR90.DLL'.
> Error, conflicting DLLs for 'MSVCR90.DLL'.

That is very strange, I am now assuming that erasing the ".dist" folder
will get you past that, can you confirm? Does it erase, because this copy
should serve us well:

    if Options.isStandaloneMode():
        standalone_dir = getStandaloneDirectoryPath(main_module)
        shutil.rmtree(standalone_dir, ignore_errors = True)

On Windows, the DLL file might be locked, if still running (maybe secretly

    for early_dll in detectUsedDLLs(standalone_entry_points):
        dll_name = Utils.basename(early_dll)

        target_path = Utils.joinpath(

        # Check that if a DLL has the name name, if it's identical,
        # happens at least for OSC and Fedora 20.
        if Utils.isFile(target_path):
            import filecmp

            if filecmp.cmp(early_dll, target_path):
                sys.exit("Error, conflicting DLLs for '%s'." % dll_name)


        if Options.isShowInclusion():
             info("Included used shared library '%s'.", early_dll)

So, no idea, except that your directory somehow starts out non-empty, even
after being discarded.

msg713 (view) Author: bosmart Date: 2014-07-13.09:16:31
scons: done building targets.
Nuitka:INFO:Included used shared library 'c:\windows\system32\GPSVC.DLL'.
Nuitka:INFO:Included used shared library 'c:\windows\system32\PYTHON27.DLL'.
Nuitka:INFO:Included used shared library 'c:\python27\lib\site-packages\wx-3.0-
Nuitka:INFO:Included used shared library 'c:\windows\system32\WSOCK32.DLL'.
Nuitka:INFO:Included used shared library 'c:\python27\MSVCR90.DLL'.
Error, conflicting DLLs for 'MSVCR90.DLL'.
msg712 (view) Author: kayhayen Date: 2014-07-12.19:10:46

I forgot that this is an error message that I actually introduced myself.
That was when it occurred
than an exception triggered, for duplicate names. But those were then
compared to be identical,
which passes, or else this "conflicting" error message was output.

In the hotfix that I just made, I added the name of the DLL in
question. Using --show-modules
you get the filenames as you did above. Please tell me the name and paths
of the DLLs that
are conflicting for you. Without the hotfix, you can likely spot it
yourself from the list of DLLs
included. From the quote above, I cannot deduce it.


2014-07-12 16:10 GMT+02:00 bosmart (via Issue Tracker) <>:

> bosmart <> added the comment:
> Nuitka:INFO:Included used shared library 'c:\windows\system32\GPSVC.DLL'.
> Nuitka:INFO:Included used shared library
> 'c:\windows\system32\PYTHON27.DLL'.
> Nuitka:INFO:Included used shared library
> 'c:\python27\lib\site-packages\wx-3.0-
> msw\wx\WXMSW30U_HTML_VC90_X64.DLL'.
> Nuitka:INFO:Included used shared library 'c:\windows\system32\WSOCK32.DLL'.
> Nuitka:INFO:Included used shared library 'c:\python27\MSVCR90.DLL'.
> Error, conflicting DLLs.
> _______________________________________________
> Nuitka issue tracker <>
> <>
> _______________________________________________
msg711 (view) Author: bosmart Date: 2014-07-12.14:10:06
Nuitka:INFO:Included used shared library 'c:\windows\system32\GPSVC.DLL'.
Nuitka:INFO:Included used shared library 'c:\windows\system32\PYTHON27.DLL'.
Nuitka:INFO:Included used shared library 'c:\python27\lib\site-packages\wx-3.0-
Nuitka:INFO:Included used shared library 'c:\windows\system32\WSOCK32.DLL'.
Nuitka:INFO:Included used shared library 'c:\python27\MSVCR90.DLL'.
Error, conflicting DLLs.
msg710 (view) Author: kayhayen Date: 2014-07-12.10:28:08

thanks for the kind words, yes, we are getting somewhere. The wxPython is a
problem child still it seems. You wrote:

I got a Dependency Walker error though at the end, something about
> conflicting DLLs so
> I copied all
> wx*.dll files and now it crashes w/o any exception info...

Can you give a details of that error. A copy & paste of the precise error
would be very helpful.

msg709 (view) Author: bosmart Date: 2014-07-11.19:06:18
The app I was trying to build for the past few months has finally built using the 
latest release of 
Nuitka (kudos!). Yet, it crashes immediately when I try to run it, although the file in 
question is at 
the location mentioned:

Traceback (most recent call last):
  File "", line 1, in <module>
  File "c:\Python27\lib\site-packages\wx-3.0-msw\wx\", line 45, in wx
    from wx._core import *
  File "c:\Python27\lib\site-packages\wx-3.0-msw\wx\", line 4, in _core
    import _core_
ImportError: LoadLibraryEx 'c:\Temp\dist-nuitka\run\wx\_core_.pyd' failed

I got a Dependency Walker error though at the end, something about conflicting DLLs so 
I copied all 
wx*.dll files and now it crashes w/o any exception info...
Date User Action Args
2015-01-07 07:23:49bosmartsetmessages: + msg937
2015-01-06 22:58:02kayhayensetstatus: chatting -> deferred
messages: + msg936
title: wxPython not working -> wxPython not working (waiting for upstream)
2015-01-05 19:20:45kayhayensetmessages: + msg931
keyword: - windows
title: wxPython standalone not working on Windows -> wxPython not working
2015-01-05 19:19:11kayhayensetmessages: + msg930
2015-01-05 00:05:27kayhayensetmessages: + msg920
2015-01-04 23:59:27kayhayensetfiles: - Screen Shot 2014-07-15 at 10.34.43.png
2014-11-16 21:56:06bosmartsetmessages: + msg837
2014-11-16 21:06:23kayhayensetmessages: + msg836
2014-11-15 08:52:33bosmartsetmessages: + msg835
2014-08-28 06:59:26kayhayensetmessages: + msg786
2014-08-28 06:57:27kayhayensetmessages: + msg785
keyword: - standalone
title: wxPython standalone not working -> wxPython standalone not working on Windows
2014-08-11 08:07:00kayhayensetassignedto: kayhayen -> bosmart
messages: + msg752
2014-07-21 21:35:16kayhayensetmessages: + msg731
2014-07-20 13:37:10bosmartsetmessages: + msg729
2014-07-20 10:38:16kayhayensetmessages: + msg728
2014-07-18 18:21:17bosmartsetmessages: + msg727
2014-07-18 17:51:39kayhayensetmessages: + msg726
2014-07-18 16:42:21bosmartsetmessages: + msg725
2014-07-18 08:09:00kayhayensetmessages: + msg724
2014-07-18 05:18:19bosmartsetmessages: + msg723
2014-07-17 08:48:10bosmartsetmessages: + msg722
2014-07-17 06:39:39kayhayensetmessages: + msg721
2014-07-17 06:24:53kayhayensetmessages: + msg720
title: wxPython standalone not working, compiled EXE crash -> wxPython standalone not working
2014-07-15 08:43:09bosmartsetfiles: + Screen Shot 2014-07-15 at 10.34.43.png
messages: + msg719
2014-07-15 07:29:45kayhayensetmessages: + msg718
2014-07-15 07:21:10bosmartsetmessages: + msg717
2014-07-15 06:32:09bosmartsetmessages: + msg716
2014-07-13 15:26:49bosmartsetmessages: + msg715
2014-07-13 11:35:17kayhayensetmessages: + msg714
2014-07-13 09:16:31bosmartsetmessages: + msg713
2014-07-12 19:10:46kayhayensetmessages: + msg712
2014-07-12 14:10:06bosmartsetmessages: + msg711
2014-07-12 10:37:51kayhayensettitle: Compiled EXE crash -> wxPython standalone not working, compiled EXE crash
2014-07-12 10:35:51kayhayensetnosy: + kayhayen
keyword: + windows, standalone
assignedto: kayhayen
2014-07-12 10:28:08kayhayensetstatus: unread -> chatting
messages: + msg710
2014-07-11 19:06:18bosmartcreate