wxWidgets-3.0: fix issues after update to 3.0.3.1

[mojca (Mojca Miklavec)]

This ticket is about update of wxWidgets-3.0 to version 3.0.3.1 fixing issues after update of wxWidgets to 3.0.3.1 in 70f32a5: .

It's slightly unlikely that wxPython 3.0.3 would be relased, at least not in the very near future. But maybe the old python additions works on top of wxWidgets 3.0.3?

I initially tried updating the port, but there were a number of issues:

• clang 425 segfaults when compiling, we should carefully check the behaviour on Slow Leopard and across some other platform verion
• if we blacklist the compiler just for wxWidgets, p5-wx segfaults in the same way, probably all other dependencies as well
• according to perl developers one should not mix the compilers and recompile perl (but I see no realist way to do that)
• perl packages fail quite a number of tests

There were some subsequent attempts to fix various bits and pieces, but most importantly wxPython is still broken and I would like to get this fixed properly.

During the process I discovered that llvm-gcc-4.2 actually seems to build wxWidgets 3.0.3.1 correctly which might be the best fix for 10.7 (maybe better than having to resort to a newer compiler?) and there are still issues with p5-wx.

It would be nice to make sure that these ports work on 10.5 and later.

Meanwhile Vadim (one of the main developers of wxWidgets) also started actively fixing my old bug reports.

[mojca (Mojca Miklavec)]

Ticket #54742 is requesting an update due to the requirement of the latest version of FileZilla. This gives an additional incentive to upgrade faster. Sorry, I didn't know there was any hurry until this point and I was still slightly hoping for another wxPython upgrade, but that seems unlikely anyway. I need to upload some patches for testing (it might take me a bit of time, any help welcome, but we need to address different version for wxWidgets and wxPython, p5-* ports, compiler testing on 10.6-10.7 etc).

[mojca (Mojca Miklavec)]

After commit 70f32a5:

• ​10.5/ppc: probably already broken before
• ​10.6/i386, ​10.6/x86: only 3.2 and libcxx broken
• ​10.7: all 3.0 flavours broken

An example of p5-wx build failure:

• ​p5-wx on 10.8

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 57e4fac68335224640c7b9b47ab99bc0c3f72697/macports-ports:

wxWidgets PG: blacklist older clang versions

Installed header files cause older version of Clang to crash.
See #54296

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In ee649fa0064287defdf0aeb80ff3479820546172/macports-ports:

wxWidgets-3.0: blacklist older clang versions

Installed header files cause older version of Clang to crash.
See #54296

[mojca (Mojca Miklavec)]

Two further tickets about wxPython failure: #55220, #54978. I have some ​patches ready, I just need to test on an older mac where it currently fails.

[kencu (Ken)]

happy to help and test it out. I'm not totally clear on quite how to checkout your patches into a local machine here, though, as they involve multiple ports and also the portgroup files.

I think I've overdone it -- I have cloned your entire macports-ports repo locally, and checked out your wxwidgets branch.

Now do I need to make a portindex in your cloned repo and then redirect my macports installation to use your repo as my source in sources.conf?

I know -- by now I should get this better, but this one seems the most complicated I've worked on so far.

[mojca (Mojca Miklavec)]

A branch behaves exactly the same as any other pull request. Once you are in an existing clone, you just need to fetch the additional code.

Here's what I usually do (PR can be ignored):

# set these up for each individual commit (no need for GH_PR, it's just for myself)
GH_PR=994
GH_USER=mojca
GB_REMOTEBR=wxWidgets-3.0.3

# everything below is copy-pasting

# LOCALBR is just how I want to name the branch myself locally
LOCALBR=pr${GH_PR}-${GH_USER}-${GH_REMOTEBR}

# fetch the remote branch (you can do the same even if there's not PR open)
git fetch git://github.com/$GH_USER/macports-ports.git $GH_REMOTEBR

# check that out in a local branch (using the name you picked before)
git checkout -b $LOCALBR FETCH_HEAD

# optional, only relevant if you want to merge it or make sure you're always on top
git rebase master

# if you want to modify someone else's branch for the sake of fixing a PR
git push -f https://github.com/$GH_USER/macports-ports.git $LOCALBR:$GH_REMOTEBR

# if you want to push the changes to master
git push origin $LOCALBR:master

(Please note: I didn't copy-paste this time, I'm in the middle of switching computers and retyping was just faster, just watch for any typos before blindly copying everything :)

If you need a portindex, you can actually copy it from the main index first and then you'll just need to process the changes. But yes, if you want to test it, it probably makes sense to at least temporarily switch to git completely. You can cheat if you only have one port, but it's easier to go for the whole tree if there are multiple ports involved.

​https://github.com/macports/macports-ports/pull/994

[kencu (Ken)]

Thanks. wxWidgets-3.0 (both versions) installs without any trouble on my day-to-day 10.6.8 system which is set up with libc++ and default_compiler macports-clang-3.9.

$ port -v installed wxwidgets-3.0-libcxx
The following ports are currently installed:
  wxWidgets-3.0-libcxx @3.0.2_4 platform='darwin 10' archs='x86_64' date='2016-12-10T00:02:46-0800'
  wxWidgets-3.0-libcxx @3.0.3_0 platform='darwin 10' archs='x86_64' date='2017-09-12T21:41:17-0700'
  wxWidgets-3.0-libcxx @3.0.3.1_0 (active) platform='darwin 10' archs='x86_64' date='2017-11-04T11:54:09-0700'

$ port -v installed wxwidgets-3.0
The following ports are currently installed:
  wxWidgets-3.0 @3.0.2_4 platform='darwin 10' archs='x86_64' date='2016-09-28T19:40:11-0700'
  wxWidgets-3.0 @3.0.3_0 platform='darwin 10' archs='x86_64' date='2017-09-10T21:51:48-0700'
  wxWidgets-3.0 @3.0.3.1_0 (active) platform='darwin 10' archs='x86_64' date='2017-11-04T11:33:44-0700'

trying wxWidgets-3.2 now, and then will run the tests you suggested in the PR to see if there are errors.

[kencu (Ken)]

wxWidgets-3.2 will not link cleanly on 10.6.8. I can get it to build by forcing it to use the 10.7SDK (like we do in libsdl2), but then it errors out in the link at the end, due to one moved framework and one missing framework on 10.6. It might or might not be possible to fix that, but I'm not up for sorting it out just now.

Here's what I did, for future prospectors who might be interested in taking this further. I added this to the wxWidgets-3.2 portfile, just after the configure args:

######  wxwidgets-3.2 - try to build on 10.6.8

platform macosx {
    if {${os.major} <= 10} {
        # Build requires at least 10.7.3 SDK, even when targeting 10.6
        set lion_sdkpath ${developer_dir}/SDKs/MacOSX10.7.sdk
        if {[file exists $lion_sdkpath]} {
            configure.sdkroot $lion_sdkpath
            configure.args-replace --with-macosx-sdk=no --with-macosx-sdk=$lion_sdkpath
            configure.args-replace --with-macosx-version-min=no --with-macosx-version-min=10.6
        } else {
            pre-fetch {
                error "Building $name @${version} on Mac OS X 10.6 requires the MacOSX10.7.sdk to be present in ${developer_dir}/SDKs/"
            }
        }
    }
}

and here are the link errors in the end, caused by differences between the 10.6 and 10.7 SDK:

--->  Cleaning wxWidgets-3.2
--->  Removing work directory for wxWidgets-3.2
--->  Updating database of binaries
--->  Scanning binaries for linking errors
Could not open /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia: Error opening or reading file (referenced from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.1/lib/libwx_osx_cocoau_media-3.1.1.0.0.dylib)
Could not open /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation: Error opening or reading file (referenced from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.1/lib/libwx_osx_cocoau_media-3.1.1.0.0.dylib)
--->  Found 2 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: wxWidgets-3.2 @3.1.0-git-20171103

So we'll leave wxWidgets-3.2 as unbuildable on < 10.7, as it currently is noted to be.

[mojca (Mojca Miklavec)]

Thank you. I'll report the problems with test failures upstream, but I won't let this stop the commit.

Getting wxWidgets 3.1 working on 10.6 would be a bit of an adventure, I'm afraid. Not impossible to do, but I guess one would really need to modify some sources. Not some trivial change anyway.

[Dygear (Mark Tomlin)]

Out of genuine curiosity, is it possible to build this now? What are the terminal commands that the "lay person" like myself would need to run in order to get this up and running today? Or is there a time frame for when this will "just work" within the sudo port upgrade command?

[mojca (Mojca Miklavec)]

In 75f44a33381d3571b5ca724b4efe837feef3b54a/macports-ports:

wxWidgets-3.0: fixes after upgrade to 3.0.3

• Update to version 3.0.3.1.
• Fetch files from wxWidgets rather than from vadz.
• Fix wxPython-3.0: properly revert to version 3.0.2 and all the corresponding required patches (accidentally broken during the upgrade to 3.0.3).
• The libc++ code and compiler blacklisting is now in the PortGroup.
• Fix livecheck.

Closes: #54296
Closes: #54978

[mojca (Mojca Miklavec)]

Replying to Dygear:

Out of genuine curiosity, is it possible to build this now? What are the terminal commands that the "lay person" like myself would need to run in order to get this up and running today?

See ​https://guide.macports.org/chunked/development.local-repositories.html. You can either manually copy files or (easier) clone the relevant branch of the relevant fork and install from there.

Or is there a time frame for when this will "just work" within the sudo port upgrade command?

I committed the changes now, so it should start working out of the box if you run selfupdate in about 30 minutes.