search

Gcenx / macports-wine

Updated wine Portfiles for macports
88 stars 11 forks source link

10.9.5 Mavericks - Problems with wine-stable #89

Closed MrLeRien closed 4 months ago

MrLeRien commented 1 year ago

hello again,

building wine-stable without gstreamer support would succeed but after it finished, macports would automatically rev-upgrade and rebuild wine on a loop.

wine would still install under /opt/local/bin, but making a new wine prefix would throw alot of errors before crashing at "could not load kernel32.dll".

below is the output of port -v install wine-stable , showcasing the rev-upgrade loop portoutputwinestable.txt

below is the output of winecfg winecfgoutput.txt

Gcenx commented 1 year ago

I can see the issue with dev-upgrade wine still linked to Metal.framework I think Brendan changed wine to always link against Metal.framework that can be reverted.

Did winecfg actually open at all or just complain about kernel32.dll?

Ether I’ll need to setup a 10.9 VM or just lock below 10.11? Ish to wine-7.x branch and below 10.8 to wine-6.x branch

MrLeRien commented 1 year ago

winecfg never opened at all, the only thing that appeared was the "wine configuraton updating" window when i made the prefix until it crashed. in this recording it would crash at "failed to load start.exe" but i feel like it fluctuates between kernel32.dll and start.exe .

https://github.com/Gcenx/macports-wine/assets/84038685/a82a1f82-ec85-4099-85ad-2b5c00a1d984

specifying WINEARCH=win32 yielded even less results.

https://github.com/Gcenx/macports-wine/assets/84038685/a2353230-036a-4eb3-a432-e66a1f5df3d7

however when i tried wine64, winecfg would actually open

https://github.com/Gcenx/macports-wine/assets/84038685/0afdd051-c216-41f1-b5f2-d0a9d1a68f2f

included wine apps / utilities would run (control, iexplore) but when i started an .exe (64 or 32 bit), it would always crash at ShellExecuteEx failed: 0024:err:start:fatal_error FormatMessage failed

https://github.com/Gcenx/macports-wine/assets/84038685/afc2abb8-068c-474c-840d-5e1fcf9cd4f1

https://github.com/Gcenx/macports-wine/assets/84038685/ec51837e-7f4a-42fe-9ea7-0227c399e859

Gcenx commented 12 months ago

Hum so below 10.10 might now require more reverts, for the moment I've added wine-stable-6.0.4 via https://github.com/Gcenx/macports-wine/commit/ebf2f2d4706133b81802232faa94c8fc8d39e973 this should be and run without issue on 10.6.8 > 10.12.

MrLeRien commented 12 months ago

can confirm wine-stable-6.0.4 builds and runs as expected on Mavericks. Just wondering are you rewriting wine-7.x to make it work on < 10.10?

Gcenx commented 12 months ago

can confirm wine-stable-6.0.4 builds and runs as expected on Mavericks.

Good that mean I can rule out possible macports-ports breakages.

Just wondering are you rewriting wine-7.x to make it work on < 10.10?

Yes that’s my next goal have a wine-stable-7 Portfile setup, then possibly wine-devel-7.x

Once that’s done I’ll revisit how to recent these portfiles to be more seamless for end-users.

MrLeRien commented 12 months ago

awesome, looking forward to seeing it! 👍

Gcenx commented 12 months ago

Added wine-stable-7.0.2 via https://github.com/Gcenx/macports-wine/commit/2402aa9ad8525cb3464f0a3d09b3cff0faae9fd2 that should work, I can't remember if I'd tested wine-devel-7.22 on 10.9 so that one's light going to be the issue.

MrLeRien commented 12 months ago

Untitled can confirm wine-stable-7.0.2 runs perfectly in my testing

Gcenx commented 12 months ago

Added wine-devel-7.22 & wine-staging-7.22 via https://github.com/Gcenx/macports-wine/commit/5b214c5ed8eb7f629a4039d383c71c8dd8a68aa5 I'm hoping that works.

Gcenx commented 12 months ago

Technically didn’t need to provide the wine-staging-7.22 subport but probably no harm in including it.

MrLeRien commented 12 months ago

i tried wine-devel-7.22 but got stuck on a libsdl2 error while it was configuring for compile. pretty confusing error, i already have libsdl2 installed by ports

output of port -v install wine-devel-7.22: wine722develportoutput.txt

main.log

Gcenx commented 12 months ago

The configure issue should be resolved via https://github.com/Gcenx/macports-wine/commit/66b094594fd1c9b4ca83bea7911e71ca826ba958.

MrLeRien commented 12 months ago

image hm and now it can't parse the port anymore, weird.

Gcenx commented 12 months ago

That’s very odd…

I’ll just strip the wine-staging-7.22 subport

Gcenx commented 12 months ago

Removed wine-staging-7.22 still weird you only get the error this time around

MrLeRien commented 12 months ago

every port now parses successfully and wine-devel passes the configure part now it's stuck in the compile :/

winedevel722portoutput.txt

main.log

Gcenx commented 12 months ago

It’s not liking the mingw headers, but as you’d build wine-8.0.2 that must mean it was fix somewhere in between, this one might take a bit more research.

I’ll firstly get this to build locally then push another commit.

Gcenx commented 12 months ago

Adding this for self reference.

https://bugs.winehq.org/show_bug.cgi?id=54263

Resolved by commit https://gitlab.winehq.org/wine/wine/-/commit/4d8091cccc46053c605e68eccd27b94ec297f28e

Gcenx commented 12 months ago

With https://github.com/Gcenx/macports-wine/commit/a8e35f9cdef69df964638eb77b1a8dc10991cd90 I’d managed to build wine64 so that should resolve the build issues at least.

MrLeRien commented 12 months ago

image built 7.22 and it works perfectly now

Gcenx commented 12 months ago

Awesome!

So the breakage happened sometime between wine-7.22 & wine-8.0

mazeltovelss commented 8 months ago

I used port install wine-stable -gstreamer early today to rebuild a homebrew wine-stable I accidentally updated last month, which lost the ability to load Diablo 2. I'm running a late-2013 MBP running Mojave 10.14.6.

The issue was the program would load to main menu, but when the procedural maps were created, the the game would crash. This issue persisted on the macport wine-stable v8.02 build. I captured the terminal of WINEDEBUG=+heap,+relay and it read:

003c:Ret PE DLL (proc=00000002282EB560,module=0000000228280000 L"msvcrt.dll",reason=PROCESS_DETACH,res=0000000000000001) retval=1 003c:Call PE DLL (proc=000000007B62F700,module=000000007B600000 L"kernel32.dll",reason=PROCESS_DETACH,res=0000000000000001) 003c:Ret PE DLL (proc=000000007B62F700,module=000000007B600000 L"kernel32.dll",reason=PROCESS_DETACH,res=0000000000000001) retval=1 003c:Call PE DLL (proc=000000017403CC00,module=0000000174000000 L"kernelbase.dll",reason=PROCESS_DETACH,res=0000000000000001) 003c:Ret PE DLL (proc=000000017403CC00,module=0000000174000000 L"kernelbase.dll",reason=PROCESS_DETACH,res=0000000000000001) retval=1 003c:Call PE DLL (proc=0000000170068FB0,module=0000000170000000 L"ntdll.dll",reason=PROCESS_DETACH,res=0000000000000001) 003c:Ret PE DLL (proc=0000000170068FB0,module=0000000170000000 L"ntdll.dll",reason=PROCESS_DETACH,res=0000000000000001) retval=1

I removed v8.02 from my system and compiled wine-stable-7.0.2, which ran Diablo 2 as expected, main menu and procedural maps. Hopefully this sheds some more light on the borking of the new Wine versions on older operating systems.

Gcenx commented 8 months ago

@mazeltovelss it’d be interesting to test wine-devel instead. You could run port deactivate wine-stable-7.0.2 so you can easily reactive it later without a complete rebuild.

As I’m on an Apple Silicon systems now upstream wasn’t even partial viable until 8.17 where upstreams wow64 became useable on Intel system (to work under rosetta2 requires hacks)

Where come up on wine-9.0 code freeze soon

Gcenx commented 4 months ago

I’ve provided alternative wine packages for legacy versions of macOS.