Trying to get modern wine working on OS X 10.6

[Gcenx]

@kencu I know you were never in favor of carrying workarounds within each Portfile but I need something to download the source archives.

So I had an idea would it be possible instead to modify portfetch.tcl to use Macports curl for older versions of OS X/macOS and have that added into the overlay and just rebase as needed?

https://github.com/macports/macports-base/blob/2c6fc24ddd1d6961afa83c5b35be12224b6850f6/src/port1.0/portfetch.tcl#L550

[kencu]

Makes sense to me. There was a reason that this idea would not fly when someone (Rene, I think) forwarded it 2 or 3 years ago... something about monitoring the download by using the library instead. Sometimes in software projects, a "good" fix never happens because the "perfect" fix is out there (but nobody ever does it).

I thought it was a pretty fine idea, myself, and used it often enough manually, until I got bored of doing that and now I have a "better" approach.

build macports, install curl, and then build it again against the installed curl, using --with-curlprefix=/opt/local.

You can install right over top of the existing one, and it all works great after that.

(what I did after that was install another macports in /opt/bootstrap to use for installing curl so that /opt/local wouldn't be self-referencing, but that is just me being fussy :> ).

[Gcenx]

Is it not possible to override portfetch.tcl via the overlay without recompiling macports-base?, I know it’s possible to override other portgroups via the overlay.

I was hoping to avoid needing to recompile, if recompiling is the only way to make use of portfetch.tcl then doing your method of having a bootstrap instal for a modern version of curl

[kencu]

well, I find recompiling and installing takes me 4 minutes, and you're done.

cd /tmp git clone -b release-2.7 https://github.com/macports/macports-base.git cd macports-base ./configure --with-curlprefix=/opt/local && make sudo make install

4 min total

[kencu]

I am not sure you can override portfetch.tcl with an overlay...I thought you had to edit it each time...but not sure.

[Gcenx]

I was hoping to avoid needing to have anyone needing to install Macports to install curl and compile Macports to force Macports curl.

If portfetch.tcl can’t be used in an overlay I’d think the other alternative would be making a duplicate that has the needed modifications renaming it then adding that as a custom Portgroup enforcing the custom version of fetch. At least then any modifications would only be done in said Portgroup if GitHub/etc change there requirements.

[kencu]

Oh, I guess I was not sure exactly what you were up to. I thought this was for your own use, on older systems, in which case the 4 minute rebuild is the way to go.

If you want a general solution for users, that is much harder. We've been working on it for years now. I can't get the MacPorts devs (after five years) to approach this issue. Must be 1000 messages on Trac about it. Fairly simple solutions, like bundling curl (easy) have been proposed, all turned down for various reasons.

What they would accept is a fairly complicated solution where MacPorts looks for a newer libcurl and uses it if present, and then falls back to the older system libcurl if it is not present. That is a huge amount of work that is fragile to maintain, I think, so I have not bitten it off, nor do I ever plan to.

As the bar for broken systems moves up (I think it's at 10.11 now) the pressure to "do something" will increase, and perhaps people's opinions might become more malleable then... not sure.

[kencu]

Your solution, BTW, still requires users to install curl before it will work, so the 4 minute rebuild might not be such a ponderous requirement. Could even be a simple shell script that would do it, probably. But again, I'm not sure of the skill set of your audience here.

[Gcenx]

Yeah I’ve read at least one ticket on the curl situation and it’s annoying to say the least.

Yeah the solution baked into the Portfiles does require installing curl but that gets added to the required packages so it installs and gets used without any real issue when tested on 10.7. Unless your thinking this wouldn’t work within a custom Portgroup?

I could properly add a script to install curl/rebuild macports-base then install it I was thinking that might the mean any potential Macports tickets would become invalid.

As for technical level for the users let’s just say I’d prefer to provided prebuilt packages for all supported versions of OS X but that brings other annoyances for me to maintain, as the from the data I’d received most users are on a more modern version of macOS so targeting 10.13 seems the most ideal.

[Gcenx]

@kencu you mentioned needing to edit the patch for wine-devel was this using the provided patch via https://github.com/Gcenx/macports-wine/tree/OSX10.6 branch?

I have attempted to install OS X 10.6 into VirtualBox but that failed miserably during the install so I’m still stuck testing from OS X 10.7.5 for now unless your aware of a clean prebuilt 10.6 image for VMWare/VirtualBox/Parallels that works. You can email me if needed it’s viable in the recent commit here.

wine-stable-6.0.1 on OS X 10.7.5

(Same image I linked on the macports tracker)

wine-devel-6.12 & wine-staging-6.12.1 also built and ran in that VM.

I’d like to confirm 10.6 and possibly 10.5 before the CX21 beta ends so we can figure out if your patch can get modified and merged into upstream wine or if anything below 10.8 will be considered unsupported as it is currently.

[kencu]

The patch for wine-staging works fine on 10.6.8 ; I tried wine-devel and that one doesn't apply.

--->  Applying patch-wine-SnowLeopard.diff
Executing:  cd "/opt/local/var/macports/build/_opt_macports-wine_x11_wine-devel/wine-devel/work/wine-wine-6.12" && /usr/bin/patch -p1 < '/opt/macports-wine/x11/wine-devel/files/patch-wine-SnowLeopard.diff'
patching file dlls/winemac.drv/window.c
Hunk #1 succeeded at 1573 (offset 5 lines).
patching file dlls/winex11.drv/pen.c
patching file dlls/ws2_32/socket.c
Hunk #1 succeeded at 464 (offset -228 lines).
Hunk #2 FAILED at 5556.
Hunk #3 succeeded at 3650 with fuzz 1 (offset -2352 lines).
Hunk #4 succeeded at 3660 with fuzz 1 (offset -2352 lines).
1 out of 4 hunks FAILED -- saving rejects to file dlls/ws2_32/socket.c.rej
Command failed:  cd "/opt/local/var/macports/build/_opt_macports-wine_x11_wine-devel/wine-devel/work/wine-wine-6.12" && /usr/bin/patch -p1 < '/opt/macports-wine/x11/wine-devel/files/patch-wine-SnowLeopard.diff'
Exit code: 1

I made a new one, attached here as a zip because github won't allow text attachments. It may be very similar or identical to the one in wine-staging, I haven't compared them as yet.

patch-wine-devel-SnowLeopard.diff.zip

[kencu]

I have 10.6.8 running on several systems as hardware, in Parallels as both a 64 bit and 32 bit VM, and also in VirtualBox as a 32bit VM. I also have it on a few USB keys as a bootable image. I originally got it with systems I purchased, but I also have downloaded the DVD from Apple https://download.developer.apple.com/Mac_OS_X/mac_os_x_version_10.6_snow_leopard_build_10a432/mac_os_x_v10.6_build_10a432_user_dvd.dmg. For some of these systems, you need a SN for MacOSX SnowLeopard Server, otherwise it will not allow you to install it.

I hope this gets you going in the right direction. There are a lot of people still using these systems it appears.

If you have not as yet reviewed macintoshgarden.org there are treasures to be found there as well, such as SnowLeopard for PPC (never released publicly).

[Gcenx]

The patch in wine-staging was created via wine-devel guess I didn't copy that over correctly when moving between my system and the VM but your attached version was fully updated where mine was lazily updated so I'll use your patch instead for wine-devel & wine-staging

Forgotten to add another required disable for wine-devel and wine-staging, --with-opencl can't be built (converted to PE format) but according to Zebediah and Alistair it's nothing to worry about so again too lazy to make a patch to revert the listed commit for 10.7 and below.

Currently downloading a 10.6.8 VMWare image that hopefully works if not I'll try using the SLS image that's also downloading. Can't use the developer.apple link as I let my developer program subscription expire.

I hope this gets you going in the right direction. There are a lot of people still using these systems it appears.

It should thanks

If you have not as yet reviewed macintoshgarden.org there are treasures to be found there as well, such as SnowLeopard for PPC (never released publicly).

Seen this place mentioned before so should check it out, almost sounds like old DreamCast sites that unreleased completed titles from the developers who just uploaded the completed games.

[Gcenx]

Progress on this will be rather slow as it seems 10.6 is missing a lot of features when compared to 10.7. Added a patch to just remove an incompatible feature for the moment.

Added an override for i686-w64-mingw32-gcc for the clang PIE patch from gcc11 Portfile hopefully that will avoid other potential issues when working on this.

The next annoyance is dlls/ntdll/unix/sockets.c, https://github.com/wine-mirror/wine/commit/b8f4061df0f71de13abc9edbeb18063d8359678f maybe I should try getting wine-6.0.1 working first.

[kencu]

10.7 did really bring macOS into the modern Posix era. Getting a current wine back to 10.7 is great work.

Supporting 10.6 and less is really just gravy; legacysupport helps a lot, but I only do significant tweaking beyond that if I'm interested.

[Gcenx]

Due to how much upstream wine has changed and keeps changing it might make more sense for me to provide wine regression commits as LegacySupport feature requests at this point.

Trying to run regression tests within a VM is beyond irritating as some of these go back to Wine-3.x and upstream is vastly different now.

[Gcenx]

Needed to fix the patch for wine-stable so at least that applies now, then found more components that are not supported until 10.7 yeah this really will take me sometime....

Going to cheat a little to just see if wine-stable can launch winecfg if this happens then I’ll continue tracking down what else is 10.7 only and go from there.

Edit; Made some progress in the right direction

So it at least started and installed my usual goto Total Annihilation, but the game crashed due to the lack of preloader so that along with multiple other components would need modifying for 10.6.

[Gcenx]

@kencu is there’s a correct way of ensuring a newer version of ld64 is installed as it seems a newer version will be required on 10.6 for

ld: unknown option: -no_new_main
clang: error: linker command failed with exit code 1 (use -v to see invocation)

That option is part of the preloader checks.

Not sure I can use enforce variant for this but if anything guess I could add it as a dependency then just set LD manually?

Assuming I could just add

require_active_variants     port:ld64 ld64_274

Well wine-preloader builds with the above version of ld64 now were back to the same issue as you had seen prior of preloader not being able to allocate memory. So unless someone is able to help figure out the workable memory ranges we might be SOL getting wine to properly work below OS X 10.7.

preloader: Warning: failed to reserve range 00001000-00010000
preloader: Warning: failed to reserve range 00010000-00110000
preloader: Warning: failed to reserve range 00110000-68000000
01e0:err:process:exec_process failed to load L"C:\\GOG Games\\Total Annihilation\\TotalA.exe" error c0000018

[kencu]

great progress! I need to be able to bootstrap to a newer ld64 on SL, for sure...for now some method of telling user is reasonable I think.

Preloader issues didn't seem to stop the things I tried from running before, but I don't really know how to test that properly, much less how to fix it....why error on 10.6 but not 10.7 I wonder????

[Gcenx]

great progress! I need to be able to bootstrap to a newer ld64 on SL, for sure...for now some method of telling user is reasonable I think.

Maybe, everything depends on preloader working correctly.

Preloader issues didn't seem to stop the things I tried from running before, but I don't really know how to test that properly, much less how to fix it....why error on 10.6 but not 10.7 I wonder????

This won’t stop something simple but .Net/mono and other more complex applications/games will run into this issue.

Preloader was built and tested on 10.7 and stayed in staging from 2.11? until 4.0-rc1 when it got merged into upstream. Unfortunately the only wine developer who might be able to help is busy with CX21/Proton. As they did add a modification for the Rosetta2 memory location.

[Gcenx]

Unfortunately I believe this is now a lost cause as upstream is now actively removing functions needed for these legacy systems due to the impending 32-on-64 work that requires almost everything be converted to PE format.

I believe it’s best to just lock these legacy systems to pre wine-4.0 as that’s before wine-preloader was introduced.

[Gcenx]

@kencu not sure this would still interest you, if you are you might want to take a look over https://github.com/Gcenx/macports-wine/commit/448b8fff83373bc344ab68c96db25c17ed924630

[kencu]

Thanks for the heads-up! I really wish the MacPorts admins would allow you to co-author or take over the Wine ports on MacPorts -- we'd leap ahead in one fell swoop!

I'll give it a look.

[Gcenx]

@kencu there‘a unfortunately nothing that can be done about that, at this point the macports-ports wine ports won’t receive any support from upstream wine since there so old I was forced to remove mention of them from the Winehq macOS wiki sections.

[Gcenx]

After dropping this I came back to try finishing this up properly with what seems to be working wine-preloader

Prior Total Annihilation would quickly crash out, now I managed to build a structure (can't really play due to no 3D acceleration under VMWare)

Not even sure how many people are still even running OS X 10.6 theses days on actual hardware but I guess it's more to prove it was possible. Due to how long it takes to build under a VM I'd simply reverted two commits to user32 instead of trying to figure out the exact culpirate.

@kencu

[Gcenx]

The updated Portfile can be found https://github.com/Gcenx/macports-wine/tree/osx10.6_legacy/x11/wine-stable-legacy

No additional custom Portfiles were added to the environment, I did however skip gstreamer components to speed up the process as I’d rather avoiding needing to build ffmpeg and friends as +universal using a VM.

[kencu]

Well done ! I know there is a following for this, will see if I can get word out.

10.6 is a strangely persistent OS version -- I run it all day, every day still, on real hardware indeed...

[Gcenx]

Done some tweaking to https://github.com/Gcenx/macports-wine/tree/osx10.6_legacy so the only Port overrides are the relevant ones, renamed to wine-stable and added wine for replaced_by function. Added wine-devel v6.13

Some of the patches lightly need work, the snowleopard one lightly needs tweaking due to building against the 10.7 SDK.

The certs patch I should probably rework simply avoid all system certs and force using the curl certs.

If there ends up being interest I’ll move these out to a new repository hopefully other enthusiastic users would also submit PRs to keep it maintained.

Edit:\ So wine-devel-6.13 doesn’t work due to 10.7 only functions added in wine-6.9, verified by building wine-6.8 and that worked (with known bugs)

So need to revert to 10.7+ related functions again…..

[kencu]

I installed wine 6.0.4 on my 10.6 system without any troubles!

Thanks!

[kencu]

I did have to do two tweaks. openldap is not actually listed as a dep, so it was not universal; added that. The FAudio cflags just were not being found via pkgconfig, so I added them manually to the configure args, beside the other one that is there.

[Gcenx]

I did have to do two tweaks. openldap is not actually listed as a dep, so it was not universal; added that. The FAudio cflags just were not being found via pkgconfig, so I added them manually to the configure args, beside the other one that is there.

Pushed a commit with those changes thanks @kencu

While I didn't see issues with FAUDIO_CFLAGS I know that can happen, for openldap while testing this I don't remember installing it within the 10.6VM, on modern versions of macOS I'd assume the macOS shipped copy is fine.

[kencu]

I really couldn't understand why pkg-config wasn't picking up the FAudio flags like it was supposed to either. I looked at configure, and ran the pkgconfig command manually... just dunno yet. Anyway, focus was getting it built, for sure, and it is!

I run this on hardware, so perhaps I can try out a few things. In particular, I like to use "Microsoft Office Document Imaging" and Scanning as that software package is just uniquely fabulous to use in a high-volume document handling environment like I use.

Thanks again Dean for finding some time and interest.

[Gcenx]

For the now blocked installing wine-devel on 10.6 until I’ve figured out what needs to be reverted.

The ideal would be getting to at least wine-6.22 working, after that really wouldn’t be worth the effort since upstream really started to take notice of the stated official minimum requirements. (Bar the current winemac.drv regression I’d reported)

[Gcenx]

Going to close this for the moment since wine-stable-6.0.4 is working on 10.6.

Might come back to this eventually to deal with wine-devel.

Still rather frustrating that Ryan continues to neglect the wine-* Ports along with MoltenVK….