Problem building wxPython 4.1.1 on MSYS2

Hi,

I am trying to build wxPython on MSYS2, from the source in the git repository. According to the README and a post that I found in this forum, there are some changes to make to the build scripts for this to work.

I have made some changes (see below) and got wxWidgets to compile, but wxPython does not yet compile. The configure step seems ok, and some of the modules are compiled and linked (235 of 958 are ok), but there is an error with sip_corecmodule.cpp.

The errors are as follows (an extract, there are many missing symbols):

../../../../sip/cpp/sip_corecmodule.cpp: In function 'PyObject* func_HandleFatalExceptions(PyObject*, PyObject*, PyObject*)':
../../../../sip/cpp/sip_corecmodule.cpp:14127:22: error: 'wxHandleFatalExceptions' was not declared in this scope; did you mean 'doc_HandleFatalExceptions'?
14127 |             sipRes = wxHandleFatalExceptions(doIt);
      |                      ^~~~~~~~~~~~~~~~~~~~~~~
      |                      doc_HandleFatalExceptions
../../../../sip/cpp/sip_corecmodule.cpp: At global scope:
../../../../sip/cpp/sip_corecmodule.cpp:19667:39: error: 'wxWEBKIT_NAV_LINK_CLICKED' was not declared in this scope; did you mean 'sipName_WEBKIT_NAV_LINK_CLICKED'?
19667 |     {sipName_WEBKIT_NAV_LINK_CLICKED, wxWEBKIT_NAV_LINK_CLICKED},
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                                       sipName_WEBKIT_NAV_LINK_CLICKED
../../../../sip/cpp/sip_corecmodule.cpp:19668:36: error: 'wxWEBKIT_NAV_BACK_NEXT' was not declared in this scope; did you mean 'sipName_WEBKIT_NAV_BACK_NEXT'?
19668 |     {sipName_WEBKIT_NAV_BACK_NEXT, wxWEBKIT_NAV_BACK_NEXT},
      |                                    ^~~~~~~~~~~~~~~~~~~~~~
      |                                    sipName_WEBKIT_NAV_BACK_NEXT
../../../../sip/cpp/sip_corecmodule.cpp:19669:41: error: 'wxWEBKIT_NAV_FORM_SUBMITTED' was not declared in this scope; did you mean 'sipName_WEBKIT_NAV_FORM_SUBMITTED'?
19669 |     {sipName_WEBKIT_NAV_FORM_SUBMITTED, wxWEBKIT_NAV_FORM_SUBMITTED},
      |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                         sipName_WEBKIT_NAV_FORM_SUBMITTED
(...)
['x86_64-w64-mingw32-g++', '-fpermissive', '-mwindows', '-UNDEBUG', '-DSIP_MODULE_NAME=wx.siplib', '-DSIP_MODULE_BASENAME=siplib', '-g', '-march=x86-64', '-mtune=generic', '-O2', '-fwrapv', '-march=x86-64', '-mtune=generic', '-O2', '-fwrapv', '-fno-strict-aliasing', '-I../../../../x86_64-w64-mingw32/lib/wx/include/msw-unicode-3.1', '-I../../../../ext/wxWidgets/include', '-Isip/siplib', '-I../../../../sip/siplib', '-Iwx/include', '-I../../../../wx/include', '-Isrc', '-I../../../../src', '-I/C:/msys64/mingw64/include/python3.8', '-DPYTHONDIR="/usr/local/lib/python3.8/site-packages"', '-DPYTHONARCHDIR="/usr/local/lib/python3.8/site-packages"', '-DHAVE_WX=1', '-DHAVE_WXADV=1', '-DHAVE_WXSTC=1', '-DHAVE_WXHTML=1', '-DHAVE_WXGL=1', '-DHAVE_WXWEBVIEW=1', '-DHAVE_WXXML=1', '-DHAVE_WXXRC=1', '-DHAVE_WXRICHTEXT=1', '-DHAVE_WXMEDIA=1', '-DHAVE_WXRIBBON=1', '-DHAVE_WXPROPGRID=1', '-DHAVE_WXAUI=1', '-D_FILE_OFFSET_BITS=64', '-DWXUSINGDLL', '-D__WXMSW__', '-D__USE_MINGW_ANSI_STDIO=1', '-D_WIN32_WINNT=0x0601', '-DNDEBUG', '-D__USE_MINGW_ANSI_STDIO=1', '-D_WIN32_WINNT=0x0601', '-DNDEBUG', '../../../../sip/cpp/sip_corecmodule.cpp', '-c', '-o/c/Users/EvanMonroig/Soft/external/Phoenix/build/waf/3.8/x64/sip/cpp/sip_corecmodule.cpp.4.o']

After different tries I have no clue about how to fix this. I don’t know etg or sip, but it seems that the file assembles many enums, some of which are not always defined depending on compilation flags.

Below are the detailed steps to reproduce the build error, from a MSYS shell:

pacman -Sy python-pip patch make mingw-w64-x86_64-libpng mingw-w64-x86_64-libjpeg-turbo mingw-w64-x86_64-libtiff mingw-w64-x86_64-gcc mingw-w64-x86_64-gcc-libs mingw-w64-x86_64-expat mingw-w64-x86_64-xz mingw-w64-x86_64-zlib 

export MINGW_PREFIX=/mingw64
export PYTHON=${MINGW_PREFIX}/bin/python.exe
export PYTHON_CONFIG="c:/msys64/usr/bin/sh.exe ${MINGW_PREFIX}/bin/python-config"
export CYGWIN_BASE=${MINGW_PREFIX}
export MINGW_CHOST=x86_64-w64-mingw32 # just for local test
export DOXYGEN=/mingw64/bin/doxygen.exe
export SIP=/mingw64/bin/sip.exe
export CC=x86_64-w64-mingw32-gcc
export CXX=x86_64-w64-mingw32-g++
export CCOMPILER=mingw32
export PATH="$PATH:/mingw64/bin"

python -m pip install virtualenv
virtualenv ./venv-msys
. ./venv-msys/bin/activate
python -m pip install requests

# python build.py clean
python build.py build_wx \
          --nodoc \
          --prefix $MINGW_PREFIX \
          --build_dir $MINGW_CHOST \
          --no_magic \
          --cairo \
          --x64 \
          --verbose \
          > test2_build_wx.log 2>&1
python build.py dox etg sip \
          --nodoc \
          --prefix $MINGW_PREFIX \
          --build_dir $MINGW_CHOST \
          > test2_dox_etg_sip.log 2>&1
python build.py build_py \
          --nodoc \
          --prefix $MINGW_PREFIX \
          --build_dir $MINGW_CHOST \
          --no_magic \
          --cairo \
          --x64 \
          --verbose \
          --python=/mingw64/bin/python3.8 \
          > test2_build_py.log 2>&1

The modified wscript, build.py and part of buildtools/ are in GitHub - emgstabilis/Phoenix at 1-build-on-msys2 (I started this branch from the tag wxPython-4.1.1). It is a work-in-progress but I do plan to clean this up after the compilation problems are resolved. Also, the steps above are organized so that they can later be transformed to a recipe for automatic build with MSYS2.

Best regards,

Evan

Some of the solutions that I tried :

  • Use MSYS python (with a virtualenv, as above, in order to use waf), or MINGW64 python (with waf provided by MSYS2) does not change the errors, except that for MINGW64 python we need to translate all paths from posix to windows-style paths
  • Use wxWidgets3.1 included in MSYS2, updated to be rebuilt on the exact same commit as in the submodule ext/wxWidgets, but with the compile options already used in MSYS2 for this package
  • Disable webview & webkit (following build wxpython with gtk2)
  • Use GTK3 instead of MS backend (produces other compilation errors which I did not investigate)
  • Disabling webkit & webview (as in Disable `WXWEBVIEW` (for GTK2 port on Fedora). · cykerway/Phoenix@bc1758f · GitHub) does not change the errors

Best regards,

Evan

I’m not sure what all might be happening, but a few things jump out at me.

  1. First, it may be easier for you to work from a source tarball (either a released one from PyPi, or one made for a snapshot build for a more up to date version of the code.) That way you will not have to deal with running the etg scripts, or doxygen or sip. I realize that since you are working towards making PRs that this seems a more complicated approach, but due to the next issues it may be easier to at least start this way.

  2. Somehow the missing wxWEBKIT_ symbols errors are not coming from the correct module. They should only be referenced from sip_webkitcmodule.cpp and since you are not building for OSX then they will be defined inside conditionally compiled code that essentially makes the class and those symbols into no-ops for the other platforms.

  3. The missing wxHandleFatalExceptions is likely due to wxWidgets being built with wxUSE_ON_FATAL_EXCEPTION set to zero. It currently needs to be set to 1 because there isn’t any workaround in place to stub it out if it’s not present in wxWidgets.

  4. As mentioned above the mac webview classes should already be properly stubbed out on anything other than OSX builds. As long as wxUSE_WEBKIT is properly set, and IIRC it should already be defaulting to 0 unless the configure script is changing it. The same goes for the WebView classes, although I’m not sure what the default for that will be in a MSYS2 build. You may need to tweak build_wxwidgets.py to force it to zero there.

Good luck.

Thanks for your thoughts.

Indeed, after building from a source tarball (4.1.1 from PyPi) to which I applied the modifications described in my previous message, the wxWEBKIT_ missing symbol errors disappeared.

The only error showing is now related to wxHandleFatalExceptions . I understand that this flag is disabled on mingw64 on windows platform.

../../../../sip/cpp/sip_corecmodule.cpp: In function 'PyObject* func_HandleFatalExceptions(PyObject*, PyObject*, PyObject*)':
../../../../sip/cpp/sip_corecmodule.cpp:14108:22: error: 'wxHandleFatalExceptions' was not declared in this scope; did you mean 'doc_HandleFatalExceptions'?
14108 |             sipRes = wxHandleFatalExceptions(doIt);
      |                      ^~~~~~~~~~~~~~~~~~~~~~~
      |                      doc_HandleFatalExceptions

Waf: Leaving directory `/c/Users/EvanMonroig/Soft/external/MINGW-packages/mingw-w64-python-wx/src/wxPython-4.1.1/build/waf/3.8/x64'
  File "/mingw64/bin/waf", line 168, in <module>
    Scripting.waf_entry_point(cwd, VERSION, wafdir)
  File "/mingw64/bin/.waf3-2.0.20-faa59322ce2ad28574604396ccd9dd97/waflib/Scripting.py", line 119, in waf_entry_point
    run_commands()
  File "/mingw64/bin/.waf3-2.0.20-faa59322ce2ad28574604396ccd9dd97/waflib/Scripting.py", line 182, in run_commands
    ctx=run_command(cmd_name)
  File "/mingw64/bin/.waf3-2.0.20-faa59322ce2ad28574604396ccd9dd97/waflib/Scripting.py", line 173, in run_command
    ctx.execute()
  File "/mingw64/bin/.waf3-2.0.20-faa59322ce2ad28574604396ccd9dd97/waflib/Scripting.py", line 375, in execute
    return execute_method(self)
  File "/mingw64/bin/.waf3-2.0.20-faa59322ce2ad28574604396ccd9dd97/waflib/Build.py", line 93, in execute
    self.execute_build()
  File "/mingw64/bin/.waf3-2.0.20-faa59322ce2ad28574604396ccd9dd97/waflib/Build.py", line 100, in execute_build
    self.compile()
  File "/mingw64/bin/.waf3-2.0.20-faa59322ce2ad28574604396ccd9dd97/waflib/Tools/errcheck.py", line 140, in check_compile
    ret=self.orig_compile()
  File "/mingw64/bin/.waf3-2.0.20-faa59322ce2ad28574604396ccd9dd97/waflib/Build.py", line 176, in compile
    raise Errors.BuildError(self.producer.error)
  File "/mingw64/bin/.waf3-2.0.20-faa59322ce2ad28574604396ccd9dd97/waflib/Errors.py", line 26, in __init__
    WafError.__init__(self,self.format_error())

Build failed
 -> task in '_core' failed with exit status 1:
        {task 123145288138080: cxx sip_corecmodule.cpp -> sip_corecmodule.cpp.4.o}
['/mingw64/bin/g++', '-march=x86-64', '-mtune=generic', '-O2', '-pipe', '-fpermissive', '-mwindows', '-UNDEBUG', '-DSIP_MODULE_NAME=wx.siplib', '-DSIP_MODULE_BASENAME=siplib', '-g', '-march=x86-64', '-mtune=generic', '-O2', '-fwrapv', '-march=x86-64', '-mtune=generic', '-O2', '-fwrapv', '-fno-strict-aliasing', '-I../../../../x86_64-w64-mingw32/lib/wx/include/msw-unicode-3.1', '-I../../../../ext/wxWidgets/include', '-Isip/siplib', '-I../../../../sip/siplib', '-Iwx/include', '-I../../../../wx/include', '-Isrc', '-I../../../../src', '-I/C:/msys64/mingw64/include/python3.8', '-DPYTHONDIR="/usr/local/lib/python3.8/site-packages"', '-DPYTHONARCHDIR="/usr/local/lib/python3.8/site-packages"', '-DHAVE_WX=1', '-DHAVE_WXADV=1', '-DHAVE_WXSTC=1', '-DHAVE_WXHTML=1', '-DHAVE_WXGL=1', '-DHAVE_WXWEBVIEW=1', '-DHAVE_WXXML=1', '-DHAVE_WXXRC=1', '-DHAVE_WXRICHTEXT=1', '-DHAVE_WXMEDIA=1', '-DHAVE_WXRIBBON=1', '-DHAVE_WXPROPGRID=1', '-DHAVE_WXAUI=1', '-D_FILE_OFFSET_BITS=64', '-DWXUSINGDLL', '-D__WXMSW__', '-D__USE_MINGW_ANSI_STDIO=1', '-D_WIN32_WINNT=0x0601', '-DNDEBUG', '-D__USE_MINGW_ANSI_STDIO=1', '-D_WIN32_WINNT=0x0601', '-DNDEBUG', '../../../../sip/cpp/sip_corecmodule.cpp', '-c', '-o/c/Users/EvanMonroig/Soft/external/MINGW-packages/mingw-w64-python-wx/src/wxPython-4.1.1/build/waf/3.8/x64/sip/cpp/sip_corecmodule.cpp.4.o', '-D__USE_MINGW_ANSI_STDIO=1']

It seems that this is because the compiler directive wxUSE_ON_FATAL_EXCEPTION was not declared (see this thread), and that if GCC has SEH enabled it could be added by configure option --enable-catch_segvs. A quick google search indicates that mingw64 has SEH enabled under MSYS2.

I do not know if this might work or if it is a known limitation on mingw as pointed out by wxWidgets - Users - MinGW, wxApp::OnFatalException, wxStackWalker ?

Best regards,

Evan

I’ve fixed the wrapper so wxHandleFatalExceptions will be callable from wxPython in both cases. It will be in the next snapshot build.