py38-wxpython-4.0 fails to install

[AgilentGCMS]

I am trying to install py38-wxpython-4.0, and after installing all the dependencies, the installation of py38-wxpython-4.0 fails like so:

$ port install py38-wxpython-4.0
--->  Computing dependencies for py38-wxpython-4.0
The following dependencies will be installed:
 py38-pathlib2
 wxWidgets-3.2
 wxWidgets-common
 wxWidgets_select
Continue? [Y/n]:
--->  Fetching distfiles for py38-pathlib2
--->  Attempting to fetch pathlib2-2.3.5.tar.gz from https://files.pythonhosted.org/packages/source/p/pathlib2
--->  Verifying checksums for py38-pathlib2
--->  Extracting py38-pathlib2
--->  Configuring py38-pathlib2
--->  Building py38-pathlib2
--->  Staging py38-pathlib2 into destroot
--->  Installing py38-pathlib2 @2.3.5_0
--->  Activating py38-pathlib2 @2.3.5_0
version:1
:debug:sysinfo macOS 10.15 (darwin/19.3.0) arch i386
:debug:sysinfo MacPorts 2.6.2
:debug:sysinfo Xcode 11.3.1
:debug:sysinfo SDK 10.15
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.15
:debug:main epoch: in tree: 1 installed: 1
:debug:main python38 3.8.1_1 exists in the ports tree
:debug:main python38 3.8.1_1  is the latest installed
:debug:main python38 3.8.1_1  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants:
:debug:main Changing to port directory: /Users/sbasu1/packages/macports/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/python38
:debug:main OS darwin/19.3.0 (macOS 10.15) arch i386
:debug:main Sourcing PortGroup select 1.0 from /Users/sbasu1/packages/macports/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main Reading variant descriptions from /Users/sbasu1/packages/macports/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Running callback portstartupitem::add_notes
:debug:main Finished running callback portstartupitem::add_notes
:debug:main No need to upgrade! python38 3.8.1_1 >= python38 3.8.1_1
:debug:main epoch: in tree: 0 installed: 0
:debug:main bzip2 1.0.8_0 exists in the ports tree
:debug:main bzip2 1.0.8_0  is the latest installed
:debug:main bzip2 1.0.8_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants:
:debug:main Changing to port directory: /Users/sbasu1/packages/macports/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/archivers/bzip2
:debug:main OS darwin/19.3.0 (macOS 10.15) arch i386
:debug:main Reading variant descriptions from /Users/sbasu1/packages/macports/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Running callback portstartupitem::add_notes
:debug:main Finished running callback portstartupitem::add_notes
:debug:main No need to upgrade! bzip2 1.0.8_0 >= bzip2 1.0.8_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main expat 2.2.9_0 exists in the ports tree
:debug:main expat 2.2.9_0  is the latest installed
:debug:main expat 2.2.9_0  is active
:debug:main Merging existing variants '' into variants
...skipping...
--->  Cleaning py38-pathlib2
--->  Fetching distfiles for wxWidgets-common
--->  Attempting to fetch wxwin.m4 from https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.2/
--->  Attempting to fetch wx.bkl from https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.2/build/bakefiles/wxpresets/presets/
--->  Attempting to fetch wx_presets.py from https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.2/build/bakefiles/wxpresets/presets/
--->  Attempting to fetch wx_unix.bkl from https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.2/build/bakefiles/wxpresets/presets/
--->  Attempting to fetch wx_win32.bkl from https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.2/build/bakefiles/wxpresets/presets/
--->  Attempting to fetch wx_xrc.bkl from https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.2/build/bakefiles/wxpresets/presets/
--->  Verifying checksums for wxWidgets-common
--->  Extracting wxWidgets-common
--->  Configuring wxWidgets-common
--->  Building wxWidgets-common
--->  Staging wxWidgets-common into destroot
--->  Installing wxWidgets-common @3.1.2_0
--->  Activating wxWidgets-common @3.1.2_0
--->  Cleaning wxWidgets-common
--->  Fetching distfiles for wxWidgets_select
--->  Verifying checksums for wxWidgets_select
--->  Extracting wxWidgets_select
--->  Configuring wxWidgets_select
--->  Building wxWidgets_select
--->  Staging wxWidgets_select into destroot
--->  Installing wxWidgets_select @1.0_1
--->  Activating wxWidgets_select @1.0_1
--->  Cleaning wxWidgets_select
--->  Fetching distfiles for wxWidgets-3.2
--->  Attempting to fetch wxWidgets-3.1.2.tar.gz from https://github.com/wxWidgets/wxWidgets/tarball/v3.1.2
--->  Verifying checksums for wxWidgets-3.2
--->  Extracting wxWidgets-3.2
--->  Applying patches to wxWidgets-3.2
--->  Configuring wxWidgets-3.2
--->  Building wxWidgets-3.2
--->  Staging wxWidgets-3.2 into destroot
--->  Installing wxWidgets-3.2 @3.1.2_0
--->  Activating wxWidgets-3.2 @3.1.2_0
--->  Cleaning wxWidgets-3.2
--->  Fetching distfiles for py38-wxpython-4.0
--->  Attempting to fetch wxPython-4.0.7.post2.tar.gz from https://files.pythonhosted.org/packages/source/w/wxPython
--->  Verifying checksums for py38-wxpython-4.0
--->  Extracting py38-wxpython-4.0
--->  Configuring py38-wxpython-4.0
--->  Building py38-wxpython-4.0
Error: Failed to build py38-wxpython-4.0: command execution failed
Error: See /Users/sbasu1/packages/macports/var/macports/logs/_Users_sbasu1_packages_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-wxpython-4.0/py38-wxpython-4.0/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port py38-wxpython-4.0 failed

[Veence (Vincent)]

Could you report the output of:

port installed | grep wx

and of:

port installed | grep sip

Thanks!

[AgilentGCMS]

$ port installed | grep wx
  wxWidgets-3.2 @3.1.2_0 (active)
  wxWidgets-common @3.1.2_0 (active)
  wxWidgets_select @1.0_1 (active)

$ port installed | grep sip

had no results.

[Veence (Vincent)]

Ah, that might be the culprit.

Please do:

port install py38-sip

and try again. I might have overlooked that dependency.

[AgilentGCMS]

OK, I did as you asked, py38-sip is now installed, but building py38-wxpython-4.0 still fails. New log attached.

[AgilentGCMS]

New main.log

[Veence (Vincent)]

This has little to do with the error, but why do you install it from source instead of using the binaries?

[Veence (Vincent)]

Never mind my previous message. The error stems from the fact that the building process doesn’t find the HIWebView.h file in the 10.15 SDK. Indeed, this file has been removed in the upgrade from 10.14 to 10.15, as you can easily find out if you examine both SDKs.

However, the building process shouldn't try to compile the associated WebKit code, especially since it clearly indicates that it won’t do so because it fails to include the missing file. This seems to be a bug.

I’m going to explicitly disable the building of wxWebView, which causes the error, for 10.15. Is this a bug in the Apple SDK? I have no clue.

[AgilentGCMS]

OK, understood. Did you update the macports tree with this change? I did a port selfupdate, followed by a port clean of that port, followed by a build, and I still have an error. New error log attached.

$ port install py38-wxpython-4.0
--->  Computing dependencies for py38-wxpython-4.0
--->  Fetching distfiles for py38-wxpython-4.0
--->  Verifying checksums for py38-wxpython-4.0
--->  Extracting py38-wxpython-4.0
--->  Configuring py38-wxpython-4.0
--->  Building py38-wxpython-4.0
Error: Failed to build py38-wxpython-4.0: command execution failed
Error: See /Users/sbasu1/packages/macports/var/macports/logs/_Users_sbasu1_packages_macports_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-wxpython-4.0/py38-wxpython-4.0/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port py38-wxpython-4.0 failed

[Veence (Vincent)]

No I hadn't committed a patch yet. I just did it. Please allow for the new Portfile to propagate, and try again.

[AgilentGCMS]

I just tried again, thinking that 10 hours should have been enough for the portfile to propagate. After a 'port selfupdate', the version I'm getting now is py38-wxpython-4.0 @4.0.7. However, the build still fails. New main.log attached.

[Veence (Vincent)]

Good news is that the former error seems to have disappeared.

The new one might be caused by the extra option I added in the last iteration. Since it is not required for the port to work, I have back-pedalled.

Give it a try when you can. I apologise for this trial and error procedure, but as you might have figured out, I didn't upgrade to 10.15 so I have more or less to fire shots in the dark.

[AgilentGCMS]

OK, tried the new one (assuming that the portfile got updated in the last 4 hours). Still no dice, see new log attached.

I appreciate your patience figuring this out.

[Veence (Vincent)]

The old error is back. Strange. I have committed a Portfile where I have disabled about all I could find that was related to webview/webkit. Please take a crack at it.

[AgilentGCMS]

Sorry, still no luck. New log attached.

[Veence (Vincent)]

I just checked out that all the options to disable webkit related stuff had been correctly parsed at configure time, which they are. So, the build shouldn't attempt to deal with that stuff. Unfortunately, it stubbornly doesn’t give a hoot about this options, it seems. I’m going to report that upstream, meanwhile I’ll try to find a kludge, such as crossing out the relevant line in the makefile.

[Veence (Vincent)]

Ah, never mind. It might be simpler than that. Just have a look at ​https://github.com/wxWidgets/Phoenix/issues/1506.

[AgilentGCMS]

So did you backport that patch? If so I'll try building again.

[AgilentGCMS]

After a day's gap, I tried a port selfupdate followed by another attempt, it still fails. New log attached.

[Veence (Vincent)]

Yeah, I hadn't time to back port the patch these last days. Sorry for the delay, will try to snatch a moment tomorrow to do this.

[AgilentGCMS]

Is a backport committed yet? I'd like to try again.

[Veence (Vincent)]

I've committed the patch. Try again.

[AgilentGCMS]

Still no dice. New main.log attached.

[Veence (Vincent)]

Then the patch is wrong. :(

Another thing I could try is using the external wxPython install. TBH, at this point, wxPython doesn’t even depend on wxWidgets, given that it links against its own internal version. But since wxWidgets 3.1.2 works on 10.15, wxPython should be able to build on the external library rather than recompile its own wxPython.

I’m going to try and have a go at this.

[AgilentGCMS]

Did you get a chance to work on this? I just tried, and it still doesn't install.

[ra1nb0w]

with wxwidgets 3.1.3 same failure

[Veence (Vincent)]

I’m sorry, I’m really super-snowed under lately. I’ll try to do that before Friday. Pinkie promise.

[Veence (Vincent)]

I just had a crack at it. Doesn’t work with external wxWidgets as yet. There are double defined symbols and missing symbols errors. At that point, I’m waiting for the wxWidgets port to be hiked up to 3.1.3. Maybe it’ll work with that new version of the toolkit.

[AgilentGCMS]

I doubt it, as another person reported, wxwidgets 3.1.3 gives the same failure.

You say "with external wxWidgets". Is there a way to get wxpython working without external wxwidgets?

[Veence (Vincent)]

That’s the mode wxPython 4.0 is built by default: using an embedded WxPython distribution, which unfortunately is lagging in terms of release (I think it’s a 3.0.x one) and therefore does not compile on MacOS 10.15. My intention was to try and rely on the WxWidgets 3.1.2 port as available in MacPorts, but I think the problem stems from the fact that the SIP prototypes, which are based on the "packed in" WxPython version, are out of sync with the MacPorts 3.1.2 version.

If this assumption turns out to be right, then it might be easy to fix: only (let's hope) a minor patches to sip prototypes. I’m gonna have a deeper look into it this weekend.

[Veence (Vincent)]

I meant wxWidgets 3.1.2, not WxPython, of course. Sorry for the confusion

[ra1nb0w]

FYI: wxWidgets-3.2 is now at 3.1.3

[ra1nb0w]

this ​https://github.com/macports/macports-ports/pull/6829 should fix the problem

[Davide Gerhard <ra1nb0w@…>]

In bceb6190e4b6d4d19c0bf512307f683165b2396e/macports-ports (master):

py-wxpython-4.0: fix build on macOS 10.15

Closes: #60056

[ra1nb0w]

merged. Try out and report if it works also for you. (tested with quisk SDR in my case)