wine: Update to version 9.x

[syurin-nagatuki]

Please add wine7.0 stable version. The stable version of wine7.0 has been released. I think the new version is a very important version that allows you to run the x86_64 API on arm hosts. Please update the port.

[ryandesign (Ryan Carsten Schmidt)]

I have had work in progress for some time on restructuring and updating the 3 wine ports (wine, wine-devel, wine-crossover) to enable the use of wine32on64 but I am not ready to commit it yet.

[kencu (Ken)]

There are some standalone current wine versions available thst you can install until it is available from macports, btw.

They do not conflict with anything in macports.

​https://github.com/Gcenx/macOS_Wine_builds/releases

[Gcenx]

Replying to ryandesign:

I have had work in progress for some time on restructuring and updating the 3 wine ports (wine, wine-devel, wine-crossover) to enable the use of wine32on64 but I am not ready to commit it yet.

I really wouldn’t waste the effort on rebasing 32on64 onto upstream wine when there CX22 in a couple of months that will be based on wine-7.0. Upstream won’t accept the bug reports for wine-stable/devel when additional patches are applied.

Replying to kencu:

There are some standalone current wine versions available thst you can install until it is available from macports, btw.

They do not conflict with anything in macports.

​https://github.com/Gcenx/macOS_Wine_builds/releases

I’ll just assume most are not subscribed to wine-devel mailing list but the packages provided there are officially sanctioned my Winehq meaning any bug reports are valid. Gijs and myself have been rather busy but the plan is to eventually push them directly to Winehq for download.

Though it would be nice if upstream completes enough of the WoW64 for macOS to function without 32Bit libraries before we’re done.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Gcenx:

Replying to ryandesign:

I have had work in progress for some time on restructuring and updating the 3 wine ports (wine, wine-devel, wine-crossover) to enable the use of wine32on64 but I am not ready to commit it yet.

I really wouldn’t waste the effort on rebasing 32on64 onto upstream wine when there CX22 in a couple of months that will be based on wine-7.0.

To clarify, I am not rebasing 32on64 onto wine. I am restructuring the wine, wine-devel, and wine-crossover ports to resolve several outstanding issues, one of which is to allow the wine-crossover port to be able to use 32on64.

Upstream won’t accept the bug reports for wine-stable/devel when additional patches are applied.

Like many MacPorts ports, wine and wine-devel already apply patches for various reasons. It should present no difficulties for upstream to accept bug reports from us if the bugs are unrelated to what is being patched.

[kencu (Ken)]

Edit: I deleted this comment as my opinion on this was not relavent.

[Gcenx]

Apologies for the tardy response I don’t check the “wine” related issues here much.

Replying to ryandesign:

To clarify, I am not rebasing 32on64 onto wine. I am restructuring the wine, wine-devel, and wine-crossover ports to resolve several outstanding issues, one of which is to allow the wine-crossover port to be able to use 32on64.

That makes sense considering there very outdated for the current upstream wine structure. I’d still holdout on bumping wine-crossover until CX22 that’s now based on wine-7.6 meaning the structure matches upstream.

Replying to ryandesign:

Like many MacPorts ports, wine and wine-devel already apply patches for various reasons. It should present no difficulties for upstream to accept bug reports from us if the bugs are unrelated to what is being patched.

This depends on the who/what/when/why of the patches. Patches that tweak things for Macports infrastructure may make sense in some cases.

Applying reverts for major breakages like bug 52354 makes sense when applied for 10.13 and below, but will require a note that explains this so this can be included in the bug report.

Replying to kencu:

Gijs and myself are the actual Winehq macOS package maintainers not simply de facto anymore, that’s why brew agreed to provide the packages we’re providing on GitHub. We’re awaiting the winemac.drv regression (bug 52354) to be resolved before moving forward with pushing packages directly to Winehq.

The Winehq wine minimums requires are macOS 10.8 with the MacOSX10.10.SDK (mingw is required), once bug 52354 gets resolved I’ll ask to have it fast tracked into the next stable bump.

[Gcenx]

I doubt it will go anywhere but I’ve opened a PR with more macports like updates for wine and wine-devel Portfiles bringing them more inline with the the new Winehq macOS packages.

[raimue (Rainer Müller)]

The current stable version of wine would be 9.0 as of now, while development is at version 9.5.

[raimue (Rainer Müller)]

For those landing here in the search of an update of wine in MacPorts, I found this external ports tree with updated wine versions: ​https://github.com/Gcenx/macports-wine

[kencu (Ken)]

It’s been many years since wine was updated on macports — so many years that hardly anyone uses it:

​https://ports.macports.org/port/wine/stats/

Gcenx came along some years ago, and uses macports strong build system to build the current wine offerings distributed by homebrew and by upstream wine.

The wine-stable offering from brew lists a bit over 110,000 installs this year.

He has tried to offer these updates to macports but essentially has always been blocked in so doing, so he just set up his own repo and does it there instead.

[Gcenx]

Upstream wine will soon officially require macos Catalina (10.15.4) and later this matches CrossOver-24.

I’ve split macports-wine into two branches, main for macOS Catalina 10.15.4 and later, Legacy for macOS Snow Leopard (10.6.8) to macOS Mojave

macOS Mojave requires MacOSX10.13.sdk as macports-base doesn’t support using macOS_SDK_headers_for_macOS_10.14.pkg see ​https://developer.apple.com/documentation/xcode-release-notes/xcode-10-release-notes

The main branch is my primary focus and does override more ports than the legacy branch, main also overrides gstreamer1-* ports and some related ports to improve media foundation support in wine that does however conflict with macports-ports. I’ve started to consider ether using an isolated custom gstreamer port just for wine or simply make use of GStreamer.framework but how that’s currently handled is far from macports like.

I guess it’s possible to recreate Cerbero packing stage to GStreamer.framework and copy everything into place but that’ll be a lot of effort for something that’ll only live in my overlay anyway.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Gcenx:

Upstream wine will soon officially require macos Catalina (10.15.4)

Do you know why?

[Gcenx]

Replying to ryandesign:

Replying to Gcenx:

Upstream wine will soon officially require macos Catalina (10.15.4)

Do you know why?

Dropping legacy macOS versions means being able to take advantage of modern objective-C features, being able to use ARC and the Winehq macOS buildbot is also running macOS Catalina (using brew). Theres additional features to be added to msync and the macOS version of NTSync that will require newer versions on macOS.

The reason for 10.15.4 is (what I’m pushing for) as 10.15.0 to 10.15.3 requires an entitlement to use i386_ldt.

Thats just some of the reasons for this change, it’s not like macports has platform data to show there’s x amount of macOS 10.x users running wine. I can reference the official Winehq packages that only support macOS Catalina and the amount of downloads this year alone.

[ryandesign (Ryan Carsten Schmidt)]

I was just trying to ascertain if this is one of those "requirements" that's really more about compiler version, like in so many other projects, which wouldn't apply in MacPorts since we have newer compilers on older systems.

What Winehq uses for their buildbot, for example, is irrelevant to us.

ARC—automatic reference counting—was introduced in Mac OS X 10.7, as I recall.

I'm not sure to what extent using modern Objective-C features requires only a newer compiler or also support from OS libraries.

I suppose it has been so many years since I last looked into wine that I have essentially no idea about anything wine-related anymore you should just take these ports over. I haven't maintained them well these past years.