Building wxPython 4.0.1 in cygwin

SO, I tried with wxPython 4.0.6 and Python 3.6 and 3.7, but in both cases I
get this error. Apologies in advance because this is long, but I don't know
what the relevant parts are.

Any ideas?

···

--
Sent from: http://wxpython-users.1045709.n5.nabble.com/

Hi Robin,

Sorry for slow reply, and for the large amount of terminal output here.

So, I tried what you suggested, and encountered the error documented here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892237 .
Seeing as this was fixed in a new wxPython release, I thought I’d try building 4.0.6 instead. When I tried the build_py command for that, I instead got this error, the causes of which I am uncertain:

[ 11/868] Linking build/waf/3.7/gtk2/siplib.cpython-37m-i386-cygwin.dll [ 12/868] Compiling sip/cpp/sip_corewxMemoryBuffer.cpp [ 15/868] Compiling sip/cpp/sip_corewxAccessible.cpp [ 16/868] Compiling sip/cpp/sip_corewxMaximizeEvent.cpp sip/siplib/apiversions.c.1.o: In functionsipInitAPI’:
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/…/…/…/…/sip/siplib/apiversions.c:132: undefined reference to PyCFunction_NewEx' /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:135: undefined reference toPyDict_SetItemString’
sip/siplib/apiversions.c.1.o: In function sipGetAPI': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:189: undefined reference toPyArg_ParseTuple’
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/…/…/…/…/sip/siplib/apiversions.c:199: undefined reference to PyLong_FromLong' /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:194: undefined reference to_imp__PyExc_ValueError’
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/…/…/…/…/sip/siplib/apiversions.c:194: undefined reference to PyErr_Format'


And so on - the output scrolls a really long way. I do have python3-devel installed, but it sounds like it’s not finding the library to link to or something. Can I specify it manually?

···

On Monday, June 10, 2019 at 11:18:23 PM UTC+1, Robin Dunn wrote:

On Monday, June 10, 2019 at 10:11:12 AM UTC-7, Hamish McIntyre-Bhatty wrote:

On Thursday, May 30, 2019 at 6:45:26 PM UTC+1, Robin Dunn wrote:

On Thursday, May 30, 2019 at 4:29:42 AM UTC-7, Hamish McIntyre-Bhatty wrote:

Update: Looks like it’s being included when SIP generates the files for example this can be found at the top of sip_core_ScrolledWindowsBase.cpp:

"

#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/scrolwin.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/window.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/gdicmn.h>

"

And so on. Is there a way I can configure SIP to avoid this?

I think the problem is happening before the SIP step. To verify, look in the generated files in sip/gen/*.sip. They probably already have the full path instead of just <wx/whatever.h> inside the generated %TypeHeaderCode blocks. If so, then it’s likely the ‘dox’ step that is incorrect. The *.sip files are generated by the ‘etg’ step, but for the most part it just pulls the include file paths directly from the XML files produced by doxygen.

HTH,

Robin

Yes, you’re right, the %TypeHeaderCode blocks also have this issue.

What should I check next? I’m not very familiar with wxPython’s source tree and build system, so I feel I’m getting way out of my depth now!

If you’re working from a wxPython tarball (rather than a git checkout, for example) and you don’t need to make changes to the etg scripts or other code gen inputs, then you shouldn’t need to run the code generation steps as it’s all there already. So I would try just the “python3 build.py build_py --use_syswx --gtk2” command you mentioned in the first message.

If you do need to make changes that require the code to be regenerated then you’ll want to look at how build.py sets things up to run the regen.sh script, which is where doxygen is run. IIRC, Doxygen makes some assumptions about the location of the header files based on the current working directory, or something like that.

Robin

Yes, those symbols should be loaded from the Python shared library. On Windows it explicitly links with the Python DLL to ensure they are correct. On linux and the like the symbols are already in memory and accessible when Python does the import of the extension module, so it does more of a soft link when building the extensions. My guess is that when doing a real cygwin build it (waf) is assuming it is more like the latter, but since it’s windows it needs to be done like the former. That’s just a guess though, you may need to dig into the builds of some other extensions and see how they’re doing it for cygwin.

(Another guess) Once you find out what is needed for the link you should be able to set LDFLAGS in the environment and waf will add that to the link command lines. So you can use it to set extra -Ldir and -llib flags.

–Robin

···

On Friday, June 28, 2019 at 2:07:57 AM UTC-7, Hamish wrote:


``
And so on - the output scrolls a really long way. I do have python3-devel installed, but it sounds like it’s not finding the library to link to or something. Can I specify it manually?

Thank you very much for all of your help. I’m now much closer than before, using the command:

LDFLAGS="-L/usr/lib -lpython3.7m -lX11 -lgtk-3 -lgdk-3" python3.7 build.py build_py --use_syswx --gtk3

``

I do eventually reach this error though, and I don’t know how to fix it:

sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZNK29sipwxRichTextFormattingDialog16GetContentWindowEv': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:178: undefined reference towxPropertySheetDialog::GetContentWindow() const’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN29sipwxRichTextFormattingDialog11AddBookCtrlEP7wxSizer': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:848: undefined reference towxPropertySheetDialog::AddBookCtrl(wxSizer*)’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN29sipwxRichTextFormattingDialog14CreateBookCtrlEv': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:865: undefined reference towxPropertySheetDialog::CreateBookCtrl()’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN29sipwxRichTextFormattingDialog13CreateButtonsEi': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:881: undefined reference towxPropertySheetDialog::CreateButtons(int)’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN29sipwxRichTextFormattingDialog12LayoutDialogEi': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:899: undefined reference towxPropertySheetDialog::LayoutDialog(int)’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN21wxPropertySheetDialogC4Ev': /usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference tovtable for wxPropertySheetDialog’
/usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference to wxPropertySheetDialog::Init()' sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In functionZN21wxPropertySheetDialogD4Ev’:
/usr/include/wx-3.0/wx/generic/propdlg.h:79: undefined reference to vtable for wxPropertySheetDialog' sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In functionZN21wxPropertySheetDialogC4Ev’:
/usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference to vtable for wxPropertySheetDialog' /usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference towxPropertySheetDialog::Init()’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN21wxPropertySheetDialogD4Ev': /usr/include/wx-3.0/wx/generic/propdlg.h:79: undefined reference tovtable for wxPropertySheetDialog’
collect2: error: ld returned 1 exit status

``

Is my system wxwidgets too old? I might be able to build a newer one, but would be good to not do that if possible :slight_smile:

Hamish

···

On Tuesday, July 2, 2019 at 4:08:04 AM UTC+1, Robin Dunn wrote:

On Friday, June 28, 2019 at 2:07:57 AM UTC-7, Hamish wrote:


``
And so on - the output scrolls a really long way. I do have python3-devel installed, but it sounds like it’s not finding the library to link to or something. Can I specify it manually?

Yes, those symbols should be loaded from the Python shared library. On Windows it explicitly links with the Python DLL to ensure they are correct. On linux and the like the symbols are already in memory and accessible when Python does the import of the extension module, so it does more of a soft link when building the extensions. My guess is that when doing a real cygwin build it (waf) is assuming it is more like the latter, but since it’s windows it needs to be done like the former. That’s just a guess though, you may need to dig into the builds of some other extensions and see how they’re doing it for cygwin.

(Another guess) Once you find out what is needed for the link you should be able to set LDFLAGS in the environment and waf will add that to the link command lines. So you can use it to set extra -Ldir and -llib flags.

–Robin

It’s possible. What version do you have? It could also be that the wxWIdgets was not built with all options enabled.

Or, since these are linker errors then it could be another case of library flags being incorrect. If wxWidgets was built in the normal mode then the richtext code will be in a separate lib, and the wxPropertySheetDialog will be in the core library, so you’ll want to ensure that both are being used when linking the richtext extension module, and that the core library comes first. You can pass --verbose to the build.py command line to see the actual compile and link commands being run by waf.

···

On Tuesday, July 2, 2019 at 9:34:49 AM UTC-7, Hamish McIntyre-Bhatty wrote:

Is my system wxwidgets too old? I might be able to build a newer one, but would be good to not do that if possible :slight_smile:

Robin

It is version 3.0.3.0, as reported by wx-config.

Yes, I’ve been making good use of the --verbose option :). I will do some more digging - I should be able to find what the build options were because it’s an official cygwin package for wxwidgets.

Hamish

···

On Wednesday, July 3, 2019 at 7:06:56 PM UTC+1, Robin Dunn wrote:

On Tuesday, July 2, 2019 at 9:34:49 AM UTC-7, Hamish McIntyre-Bhatty wrote:

Is my system wxwidgets too old? I might be able to build a newer one, but would be good to not do that if possible :slight_smile:

It’s possible. What version do you have? It could also be that the wxWIdgets was not built with all options enabled.

Or, since these are linker errors then it could be another case of library flags being incorrect. If wxWidgets was built in the normal mode then the richtext code will be in a separate lib, and the wxPropertySheetDialog will be in the core library, so you’ll want to ensure that both are being used when linking the richtext extension module, and that the core library comes first. You can pass --verbose to the build.py command line to see the actual compile and link commands being run by waf.

Robin

Looks like it was built with:

    --enable-optimise \
    --enable-shared \
    --enable-unicode \
    --enable-mediactrl \
    --disable-gtktest \
    --disable-rpath \
    --disable-sdltest \
    --disable-webviewwebkit \
    --with-expat \
    --with-gtk=3 \
    --without-gnomeprint --without-gnomevfs \
    --with-libpng \
    --with-libjpeg \
    --with-libiconv \
    --with-libmspack \
    --with-libnotify \
    --with-libtiff \
    --with-libxpm \
    --with-opengl \
    --with-sdl \
    --with-zlib

``

Hamish

···

On Friday, July 5, 2019 at 12:14:14 PM UTC+1, Hamish McIntyre-Bhatty wrote:

On Wednesday, July 3, 2019 at 7:06:56 PM UTC+1, Robin Dunn wrote:

On Tuesday, July 2, 2019 at 9:34:49 AM UTC-7, Hamish McIntyre-Bhatty wrote:

Is my system wxwidgets too old? I might be able to build a newer one, but would be good to not do that if possible :slight_smile:

It’s possible. What version do you have? It could also be that the wxWIdgets was not built with all options enabled.

Or, since these are linker errors then it could be another case of library flags being incorrect. If wxWidgets was built in the normal mode then the richtext code will be in a separate lib, and the wxPropertySheetDialog will be in the core library, so you’ll want to ensure that both are being used when linking the richtext extension module, and that the core library comes first. You can pass --verbose to the build.py command line to see the actual compile and link commands being run by waf.

Robin

It is version 3.0.3.0, as reported by wx-config.

Yes, I’ve been making good use of the --verbose option :). I will do some more digging - I should be able to find what the build options were because it’s an official cygwin package for wxwidgets.

Hamish

I had a look at the linker flags, and they are as you say, core is included before the richtext module. If I specify them manaully in the LDFLAGS variable, it still fails, so I think that that isn’t the problem. I’m going to guess that I need wxWidgets 3.0.4, so I’ll see if I can get that compiling.

···

On Friday, July 5, 2019 at 12:34:27 PM UTC+1, Hamish McIntyre-Bhatty wrote:

On Friday, July 5, 2019 at 12:14:14 PM UTC+1, Hamish McIntyre-Bhatty wrote:

On Wednesday, July 3, 2019 at 7:06:56 PM UTC+1, Robin Dunn wrote:

On Tuesday, July 2, 2019 at 9:34:49 AM UTC-7, Hamish McIntyre-Bhatty wrote:

Is my system wxwidgets too old? I might be able to build a newer one, but would be good to not do that if possible :slight_smile:

It’s possible. What version do you have? It could also be that the wxWIdgets was not built with all options enabled.

Or, since these are linker errors then it could be another case of library flags being incorrect. If wxWidgets was built in the normal mode then the richtext code will be in a separate lib, and the wxPropertySheetDialog will be in the core library, so you’ll want to ensure that both are being used when linking the richtext extension module, and that the core library comes first. You can pass --verbose to the build.py command line to see the actual compile and link commands being run by waf.

Robin

It is version 3.0.3.0, as reported by wx-config.

Yes, I’ve been making good use of the --verbose option :). I will do some more digging - I should be able to find what the build options were because it’s an official cygwin package for wxwidgets.

Hamish

Looks like it was built with:

    --enable-optimise \
    --enable-shared \
    --enable-unicode \
    --enable-mediactrl \
    --disable-gtktest \
    --disable-rpath \
    --disable-sdltest \
    --disable-webviewwebkit \
    --with-expat \
    --with-gtk=3 \
    --without-gnomeprint --without-gnomevfs \
    --with-libpng \
    --with-libjpeg \
    --with-libiconv \
    --with-libmspack \
    --with-libnotify \
    --with-libtiff \
    --with-libxpm \
    --with-opengl \
    --with-sdl \
    --with-zlib

``

Hamish

So @Robin , I’ve finally managed to get wxwidgets 3.0.4 to build successfully in Cygwin. I made sure to check the demo compiles and works and so on.

I went back to this, with the same command as before and I now get a new error:

[735/868] Compiling sip/cpp/sip_ribbonwxRibbonPageTabInfo.cpp
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZNK29sipwxRichTextFormattingDialog16GetContentWindowEv': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:178: undefined reference to_imp___ZNK21wxPropertySheetDialog16GetContentWindowEv’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN29sipwxRichTextFormattingDialog11AddBookCtrlEP7wxSizer': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:848: undefined reference to_imp___ZN21wxPropertySheetDialog11AddBookCtrlEP7wxSizer’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN29sipwxRichTextFormattingDialog14CreateBookCtrlEv': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:865: undefined reference to_imp___ZN21wxPropertySheetDialog14CreateBookCtrlEv’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN29sipwxRichTextFormattingDialog13CreateButtonsEi': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:881: undefined reference to_imp___ZN21wxPropertySheetDialog13CreateButtonsEi’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN29sipwxRichTextFormattingDialog12LayoutDialogEi': /home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:899: undefined reference to_imp___ZN21wxPropertySheetDialog12LayoutDialogEi’
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function ZN21wxPropertySheetDialogC4Ev': /usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference to_imp___ZTV21wxPropertySheetDialog’
/usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference to _imp___ZN21wxPropertySheetDialog4InitEv' /usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference to_imp___ZTV21wxPropertySheetDialog’
/usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference to `_imp___ZN21wxPropertySheetDialog4InitEv’

Have you got any ideas as to what might cause this?

Hamish

Yep. Link errors like that indicate that there is a missing library in the linker command. The wxPropertySheetDialog class is located in the adv lib, so try applying this patch and see if that takes care of the problem:

diff --git a/wscript b/wscript
index 4bb8334b..fbb9e3f1 100644
--- a/wscript
+++ b/wscript
@@ -254,7 +254,7 @@ def configure(conf):
                        uselib_store='WXXRC', mandatory=True,
                        msg='Finding libs for WXXRC')

-        libname = '' if cfg.MONOLITHIC else 'richtext,' # workaround bug in wx-config
+        libname = '' if cfg.MONOLITHIC else 'richtext,adv,' # workaround bug in wx-config
         conf.check_cfg(path=conf.options.wx_config, package='',
                        args='--cxxflags --libs %score,net' % libname + rpath,
                        uselib_store='WXRICHTEXT', mandatory=True,

It now builds just fine. As you can tell, I’m quite new to all of this, so thanks for being patient with all the newbie questions :slight_smile:

Unfortunately, after the build I can’t import wxpython, and it fails with the error:

$ PYTHONPATH=/home/Hamish/wxpython-build/wxPython-4.0.6 python3.7
Python 3.7.4 (default, Jul 21 2019, 15:59:45)
[GCC 7.4.0] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/Hamish/wxpython-build/wxPython-4.0.6/wx/__init__.py", line 17, in <module>
    from wx.core import *
  File "/home/Hamish/wxpython-build/wxPython-4.0.6/wx/core.py", line 12, in <module>
    from ._core import *
ImportError: No such process
>>>

The files are definitely there under wx/, so I’m wondering if it’s being thrown by the .dll extension. I’m not sure how to find which file name it’s looking for on import. I tried the -v flag, but that didn’t tell me anything more useful.

Well, that’s a new one…

I’ve done a bit of googling and it seems that other Python extensions have had this problem as well, and you’re right, it seems to be related to DLLs not being found, rather than actual processes. I haven’t seen any solid solutions or workarounds however.

It looks like the cygcheck command can examine binaries and report the dynamic libs they linked with. I would start with using that on the _core extension and the wx DLLs and see if it gives you any new clues. And use Google. A lot. :slight_smile:

In related news, I just did a gtk3 build on WSL with no problems. That’s not too surprising though since that’s almost identical to a real Linux distro and cygwin is very definitely not.

Hmm okay, thanks for the help anyway, I’ll definitely give that a go :slight_smile:

Yep, Cygwin has certainly been a pita so far in terms of me attempting to do pretty much anything with it. It is tempting to just support WSL for my app, but I think I’m quite close to getting this working :slight_smile:

1 Like

For what it’s worth, I’ve been trying to build wxPython 4.0.6 using pip and gtk3. With just a few tweaks (added --disable-std_string and CXXFLAGS=-D_GNU_SOURCE=1 to configure_opts in buildtools/build_wxwidgets.py I got as far as undefined reference to 'PyCFunction_NewEx' and friends.

Having read the drama that you are having, and with only a very very slow Windows box (the build process takes about 4 hours before it fails) to use for the time being, I’m throwing in the towel. But I’m very keen to hear about your progress, and when I get access to a faster box I may pick it up again.

Glad to see there’s someone else interested :slight_smile: I’ve realised I haven’t given my full build command, so it is as follows:

LDFLAGS="-L/usr/lib -lpython3.7m -lX11 -lgtk-3 -lgdk-3" python3.7 build.py build_py --use_syswx --gtk3

If you use that together with Robin’s patch above for a 4.0.6 tarball, it builds, but currently doesn’t import. Unfortunately I don’t have a lot of time to figure this out at the moment, but I’ll post back here as soon as I figure something out. The build time on mine is only around 30 mins a pop, but that’s still slow enough for it to be annoying. I’m building a new Ryzen-based PC at the moment, so once that’s done I’ll probably get back to working on this. If you get anywhere please let me know :slight_smile:

Hope this helps,
Hamish

Hello again,

I managed to get as far as you have, ie the “No such process” error, and tried a few more things but now I am struggling to think of what to do next, so putting it out there in case others have an idea.

I tried cygcheck with all the wx dlls as @Robin suggested, but it didn’t report any errors and nothing jumped out at me. I then tried using strace to see which dlls Python is trying to load, and hopefully identify any problems there. I couldn’t see any sign of dll files not being found, but I did see something suspicious:

exception c0000139 at 779f94f7

Google tells me that exception c0000139 means “Entry point not found”. Which dll this relates to is not clear to me - the strace output lists the dlls being loaded but the error appears at a different place in the output in successive runs. Guessing this is related to it coming from a different process?

One thing that seems strange to me is that in other forums where the “No such process” error is discussed, the contributors seemed just to know which dll was causing the problem. Maybe they knew the insides of the modules well enough, but still if we knew which function was likely to provoke the error then maybe grep would be our friend.

That’s all for now…

Sounds like useful information. I’m glad someone else got it to go as far as me as well - reproducability always helps.

I don’t have much time at the moment, but when I do I’ll pick this back up and try to see why it’s failing.

I just tries this again, with interesting results.

import wx always returned “ModuleNotFoundError: No module named ‘wx.core’” until I cd’d to /build/waf/3.7/gtk3.

Then, import wx works without error, but there are classes available in the module. dir(wx) gives:

"['__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__']"

So this is a different but interesting error. I’m now going to try again with wxPython 3.0.7, seeing as that’s now out.

Okay, builds with wxPython 4.0.7 as well.

I now get the “No such process” error, but if I cd into build/waf/3.7/gtk3 and then try again it imports with the empty module, as above.

I’ll have a look at the “no such process” error as well and see what I find.

@Robin, does the new symptom I found reveal anything interesting/useful to you/give you any more ideas?

Hamish

The empty module is probably due to the import failing at the beginning, which is where the _core extension module is being imported.

The folder you mention is a staging folder during the build, where the wxPython extension modules are built before being copied into the ./wx folder. So, three possibilities come to mind:

  1. Something (an extension module DLL or shared lib) may not be being copied to ./wx that should be.

  2. The extension modules are being copied to ./wx but they are not being found at runtime when the import happens, but by changing into that folder it allows it to be found by virtue of it being in the cwd. If you change into the ./wx folder and try again, does the import succeed? If you add the ./wx folder to the PATH does that make any difference?

  3. The extension modules load the shared libs for wxWidgets, so if those are not able to be found at runtime then that could be a issue as well. By default the build copies those to the ./wx folder and on Windows they are found because the system looks first in the same folder as the binary which is attempting to load them (the extension modules in this case). On Linux we use the $ORIGIN trick and on OSX we use install_name_tool to accomplish basically the same thing. Perhaps cygwin needs something else to make it work?

Probably just some shots in the dark, but maybe one of them will hit something. :slight_smile: