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.

[szhorvat (Szabolcs Horvát)]

Wine themselves recommend installing with Homebrew, which has Wine 9.0: ​https://wiki.winehq.org/MacOS

Unfortunately MacPorts users can't use this options, since (I'm told) the two systems don't play well together.

For this reason it would be very useful to update Wine within MacPorts.

[Gcenx]

Replying to ryandesign:

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.

Thats not usually the case for wine at least.

Replying to ryandesign:

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

It does matter as that’s the lowest version that upstream tests against on a regular basis as there’s no usable data from macports buildbots for modern wine.

Replying to ryandesign:

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

True.

Replying to ryandesign:

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

Usually it more falls on macOS as when I was testing on legacy versions of macOS I was using macports latest compiler.

Replying to ryandesign:

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.

I’ll get everything in place nicely before making some related PRs then.

Replying to szhorvat:

Wine themselves recommend installing with Homebrew, which has Wine 9.0: ​https://wiki.winehq.org/MacOS

Yes I recommend installing via brews cask system, the actual packages are currently hosted at ​https://github.com/Gcenx/macOS_Wine_builds. You will need to install the latest gstreamer pkg release.

Replying to szhorvat:

Unfortunately MacPorts users can't use this options, since (I'm told) the two systems don't play well together.

Thats definitely not something I’d recommend an average user attempt.

Replying to szhorvat:

For this reason it would be very useful to update Wine within MacPorts.

Honestly updating them will be a nightmare as someone will complain about there macOS version being dropped. I can realistically support 10.15.4 and later. The only thing I can offer below 10.15 is being locked to an older version of wine where 6.0.4 will be the oldest.

[kencu (Ken)]

Replying to szhorvat:

Wine themselves recommend installing with Homebrew, which has Wine 9.0: ​https://wiki.winehq.org/MacOS

Interesting perhaps to recognize in the background that those packages for wine that are being distributed as installable "casks" by homebrew are in fact being made with MacPorts :>

[kencu (Ken)]

Replying to Gcenx:

Honestly updating them will be a nightmare as someone will complain about there macOS version being dropped. I can realistically support 10.15.4 and later. The only thing I can offer below 10.15 is being locked to an older version of wine where 6.0.4 will be the oldest.

OK. It is time for this kind of crippling hold-back of progress to support ancient hobby systems to stop.

Move wine and all it's dependencies up to current versions, and if that breaks the dinosaurs along the way, so be it.

I of course have been a proponent of keeping these older systems going, but never at the expense of progress for current systems. I have worked over the years to help keep the compilers and toolchains on older systems current so they won't need special considerations to build. I invented "legacysupport" and worked to bring it up to speed for the same reason -- so that people would not need to even be aware of the older system.

But there was never an intention to hold back or artificially cripple progress on newer systems to support these dinos.

Move wine along. MacPorts is too good of a build system for it to be dumped into the dustbin because support for ancient systems couldn't be maintained reliably.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Gcenx:

Honestly updating them will be a nightmare as someone will complain about there macOS version being dropped. I can realistically support 10.15.4 and later. The only thing I can offer below 10.15 is being locked to an older version of wine where 6.0.4 will be the oldest.

I agree with Ken: don't worry about that. The wine 4.0.4 in MacPorts today cannot install on the six most recent macOS versions. Getting a wine that works on recent macOS is important; supporting old systems isn't. I haven't been deliberately holding the wine ports back for support of old systems; rather, I had to essentially rewrite the entire portfile to support Crossover's custom build of clang that did whatever they were doing to support wine32on64, and I never quite completed that work. Then it got buried somewhere in my git stash and my inexperience with git made me unable to locate it anymore. Meanwhile, you updated your fork of the wine ports in another way that is evidently working well for you so let's just go with that.

[Gcenx]

I've opened some PRs for some of the ground work

• ​https://github.com/macports/macports-ports/pull/23886 d3dmetal
• ​https://github.com/macports/macports-ports/pull/23887 wine-gecko
• ​https://github.com/macports/macports-ports/pull/23888 wine-mono

However the current macports insistence on +x11 for everything even for modern systems needs to be revised, all upstream projects more or less get feedback from brew thats like always building for macports +quartz

Like gstreamer1 Ports are currently still +x11 this will mean loosing access to applemedia plugins that wine expects to have access too, I've love to fallback to simply using GStreamer.framework like I currently do to avoid this problem but I don't know a nice way to unpack the pkg to drop into ${prefix}/Library/Frameworks

[kencu (Ken)]

It is time to have the official "quartz" discussion I guess.

A bunch of things that people want in gnome cannot build quartz, and only exist as x11 variants, however.

This is not the location for that chat, There is a sorta ticket about it that not many follow. Probably best to open it up to the dev mailing list and let the feathers fly there.

[Gcenx]

For right now I’m going to build against the current macports-ports gstreamer1 +x11, if that ends up causing issues then I’ll need to investigate ether unpacking the gstreamer pkg installers so GStreamer.framework can be used or figure out how to make Cerbero work within a Portfile to make gstreamer.framework.

[Gcenx]

Once all the above packages and the mingw-w64 gcc/binutils updates have all landed on packages.macports.org I can at least add game-porting-toolkit, there’s still one more new port I’d like to that I’ll submit after work.

wine-stable, wine-devel & wine-staging will only support macOS Catalina & later, with permission from CodeWeavers I’ll be also applying some required hacks to workaround some known bugs especially when running under Rosetta2 these will be applied flat. The current wine port will become a stub to install wine-stable and possible legacy variants see below.

If someone wants to help fix up mingw-gcc on legacy versions of macOS I do have alternative wine-* packages.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Gcenx:

I can at least add game-porting-toolkit

Assuming this will use the same distfile already mentioned in the d3dmetal portfile, please add the line dist_subdir game-porting-toolkit to the d3dmetal portfile.

[Gcenx]

Replying to ryandesign:

Replying to Gcenx:

I can at least add game-porting-toolkit

Assuming this will use the same distfile already mentioned in the d3dmetal portfile, please add the line dist_subdir game-porting-toolkit to the d3dmetal portfile.

Different distfile, game-porting-toolkit is a custom version of wine-crossover-22.1.1, d3dmetal is runtime dependency that allows Direct3D (64-bit 11/12) to run on-top of Metal.

[Gcenx]

Submitted game-porting-toolkit ​https://github.com/macports/macports-ports/pull/24127

This was rewritten to be as macports like as possible.

[Gcenx]

Submitted wine-stable ​https://github.com/macports/macports-ports/pull/24317

[Gcenx]

And now we’re onto wine-devel & wine-staging ​https://github.com/macports/macports-ports/pull/24442

[thetrial (alabay)]

Ah, I see … it seems my problems with gstreamer1 stuff comes from my wine-installation … #69643 and #70332. So if I exclude wine from updates MP can go through upgrading. But why is wine shown as runnig under Sierra? ​https://ports.macports.org/port/wine-devel/details/ … I am on Sierra and have wine-devel. And (unfortunately) my system is not hobby but stuck on non-supported (too good and expensive) hardware.

[Gcenx]

Replying to thetrial:

Ah, I see … it seems my problems with gstreamer1 stuff comes from my wine-installation … #69643 and #70332. So if I exclude wine from updates MP can go through upgrading. But why is wine shown as runnig under Sierra? ​https://ports.macports.org/port/wine-devel/details/ … I am on Sierra and have wine-devel. And (unfortunately) my system is not hobby but stuck on non-supported (too good and expensive) hardware.

What details shows is at some point wine-devel build successfully on macOS Sierra not that it supports it currently. wine-stable, wine-devel & wine-staging only support macOS Catalina and later.

If you’d like to volunteer yourself to help test building on macOS Sierra it would be best to open a new ticket with me as the owner.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Gcenx:

What details shows is at some point wine-devel build successfully on macOS Sierra not that it supports it currently.

Not just "at some point", but specifically the last time a build was attempted, which was in 2021. The port currently indicates that it does not support Sierra so builds are no longer attempted on Sierra.

The ports web site needs to be smarter about this. It needs to associate build status information with the version of the port and clear out status information that is not for the version of the port that is currently available. This is ​https://github.com/macports/macports-webapp/issues/135.