Hmm okay, thanks for the help anyway, I’ll definitely give that a go 
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
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 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
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:
Something (an extension module DLL or shared lib) may not be being copied to ./wx that should be.
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?
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.
Has anyone else had any luck with this? I must admit I haven’t had the time to follow up on this, but I will do very soon
I’m also going to try and get the Cygwin people involved - I’m sure they’ve found and fixed similar problems in the past.
Noting that if I do a native build (Mint 19.3) there are very few notes and warnings, but when I build in Cygwin I get a lot of “type attributes ignored after type is already defined” warnings for various headers, for example cmdproc.h (and class WXDLLIMPEXP_FWD_CORE wxMenu). This happens after almost every compilation command This might be because I’m using the system wxwidgets headers though, I’m not sure.
I haven’t done anything on it lately. I also got those compilation warnings and had a brief look into them at the time. I’m afraid I can’t remember the details but I do remember thinking that it was pretty unlikely they were related to the import problem.
Yeah, I’m figuring that too. I’ll probably still look into it.
What’s worth noting is that the maintainer for this package in Cygwin is retiring from the project,. I’m going to take up this package if I can eventually get it working, so I was wondering if maybe you’d like to co-maintain it with me, Jonathan?
I’m happy to lend a hand but in reality I am only an occasional user of wxPython or Cygwin. Still it would be good to see this working.
That’s fair enough
I finally have some time, so I just build 4.0.7-post2 using the same command and it Just Worked ™ for some unknown reason. 4.0.7-post1 also seems to work now, so I guess there was some issue in Cygwin causing this problem, but I don’t know what it was.
I guess I’ll get to packaging this very soon then, and we should finally have an up to date version of wxPython in Cygwin. I guess 4.1.x can come after if we need it, but it will need wxwidgets 4.1.x so eh, I’ll do that when I need to.
Well, I’ve got some test packages out at https://www.hamishmb.com/files/cygwin-temp/ (both 32 and 64 bit).
These haven’t yet been approved/disapproved by the Cygwin people, but it’d be useful if you could give them a try as well I’ve just been using the wxPython demo to test them, and it seems fine AFAICT.
These packages are now available as test packages in Cygwin
Thanks for all the help Robin and Jonathan!