February 2023 - Wine-Devel - list.winehq.org

Re: Compiling issues on macOS after 7.20 on ARM

by Brendan Shanks

> On Feb 10, 2023, at 11:10 AM, Jason Millard <jsm174(a)gmail.com> wrote: > > Hello. Thanks! > > `llvm-mingw` was a typo from my notes. Sorry about that. > > After examining paths, they looked the same, so I tried without the > > export LDFLAGS="-Wl,-rpath,/opt/X11/lib" > > and that worked and I can now make it through configure! > > > Now during the build, I get: > > dlls/ntdll/unix/dwarf.h:915:45: warning: taking the absolute value of unsigned type 'ULONG_PTR' (aka 'unsigned long') has no effect [-Wabsolute-value] > case DW_OP_abs: stack[sp] = labs(stack[sp]); break; > ^ > dlls/ntdll/unix/dwarf.h:915:45: note: remove the call to 'labs' since unsigned values cannot be negative > case DW_OP_abs: stack[sp] = labs(stack[sp]); break; > ^~~~ > <inline asm>:305:2: error: conditional branch requires assembler-local label. '.L__wine_syscall_dispatcher_return' is external. > cbnz w16, .L__wine_syscall_dispatcher_return > ^ Great, I just pushed an MR for that error: https://gitlab.winehq.org/wine/wine/-/merge_requests/2158 With that it should build, but otherwise ARM64 Wine completely does not work on macOS. But if you only need widl maybe that’s ok :) Brendan

Feb. 10, 2023

Re: Compiling issues on macOS after 7.20 on ARM

by Jason Millard

Hello. Thanks! `llvm-mingw` was a typo from my notes. Sorry about that. After examining paths, they looked the same, so I tried without the export LDFLAGS="-Wl,-rpath,/opt/X11/lib" and that worked and I can now make it through configure! Now during the build, I get: dlls/ntdll/unix/dwarf.h:915:45: warning: taking the absolute value of unsigned type 'ULONG_PTR' (aka 'unsigned long') has no effect [-Wabsolute-value] case DW_OP_abs: stack[sp] = labs(stack[sp]); break; ^ dlls/ntdll/unix/dwarf.h:915:45: note: remove the call to 'labs' since unsigned values cannot be negative case DW_OP_abs: stack[sp] = labs(stack[sp]); break; ^~~~ <inline asm>:305:2: error: conditional branch requires assembler-local label. '.L__wine_syscall_dispatcher_return' is external. cbnz w16, .L__wine_syscall_dispatcher_return ^ 1 warning and 1 error generated. make: *** [dlls/ntdll/unix/signal_arm64.o] Error 1 ➜ wine git:(6677c044abb) ✗ (BINARY-N/A) On Fri, Feb 10, 2023 at 1:33 PM Brendan Shanks <bshanks(a)codeweavers.com> wrote: > > > On Feb 10, 2023, at 5:56 AM, Jason Millard <jsm174(a)gmail.com> wrote: > > > > Hello. > > > > I’m using parts of Wine (specifically the vbscript engine) while porting > Visual Pinball to be cross platform. > > > > I have been using the WIDL utility extensively and it has worked great. > > > > I wanted to keep my patches up to date so I don’t fall behind, however I > am having issues compiling wine after version 7.20. > > > > > > This was my typical compile: > > > > > > brew install llvm llvm-mingw > > git clone -b wine-7.20 git://source.winehq.org/git/wine.git > > git clone git(a)github.com:vpinball/pinmame.git > > cd wine > > export MACOSX_DEPLOYMENT_TARGET="10.14" > > export LDFLAGS="-Wl,-rpath,/opt/X11/lib" > > export PATH="$(brew --prefix llvm)/bin:$PATH" > > export PATH="$(brew --prefix bison)/bin:$PATH" > > ./configure --without-freetype > > make -j10 > > tools/widl/widl -o ../vpinmame_i.h --nostdinc -Ldlls/\* -Iinclude > -D__WINESRC__ -D_UCRT ../pinmame/src/win32com/VPinMAME.idl > > > > > > Now with anything past 7.20 I’m getting: > > > > > > configure: error: PE cross-compilation is required for ARM64, please > install clang/llvm-dlltool/lld, or llvm-mingw. > > Hi, > > I’m not sure why you would be getting that error, can you post your > config.log? Testing on Ventura, I’m able to configure with just bison and > llvm from homebrew: > > export > PATH=/opt/homebrew/opt/llvm/bin:/opt/homebrew/opt/bison/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin > ./configure --without-freetype > > Also I don’t see an ‘llvm-mingw’ formula, where is that installed from? > > Brendan

Feb. 10, 2023

Re: Debugging channel weirdness

by Rémi Bernon

On 2/10/23 19:12, Zebediah Figura wrote: > On 2/10/23 00:18, Rémi Bernon wrote: >>> (1) Why does setting channel->flags affect performance at all? I'm >>> thoroughly baffled by this one. >>> >>> (2) Why was this diff not applied in the first place? (Simple >>> oversight?) >>> >>> (3) Why does __WINE_DBCL_INIT even exist, if its only purpose is to >>> guard out a single assignment? >>> >>> --Zeb >>> >> >> Probably to allow changing the selected channels dynamically, through >> process monitor for instance. >> > > I'm not sure which question this answers, but I don't think I understand > it? winedbg and taskmgr just set the flags directly; they don't touch > __WINE_DBCL_INIT, and I don't see why they'd need to. > > They can't change the flags in each of the translation units debug channels. What they do is change the debug options in the process PEB. In order to support the runtime modification, the TU debug channels need to keep their __WINE_DBCL_INIT bit set, so __wine_dbg_get_channel_flags is always called, and the debug option updated from the PEB. Only channels which aren't explicitly specified clear their __WINE_DBCL_INIT bit, after copying the default debug options. The default options (all) cannot be modified dynamically, or at least only takes effect the first time __wine_dbg_get_channel_flags is called for a given TU debug channel. -- Rémi Bernon <rbernon(a)codeweavers.com>

Feb. 10, 2023

Re: Compiling issues on macOS after 7.20 on ARM

by Brendan Shanks

> On Feb 10, 2023, at 5:56 AM, Jason Millard <jsm174(a)gmail.com> wrote: > > Hello. > > I’m using parts of Wine (specifically the vbscript engine) while porting Visual Pinball to be cross platform. > > I have been using the WIDL utility extensively and it has worked great. > > I wanted to keep my patches up to date so I don’t fall behind, however I am having issues compiling wine after version 7.20. > > > This was my typical compile: > > > brew install llvm llvm-mingw > git clone -b wine-7.20 git://source.winehq.org/git/wine.git > git clone git(a)github.com:vpinball/pinmame.git > cd wine > export MACOSX_DEPLOYMENT_TARGET="10.14" > export LDFLAGS="-Wl,-rpath,/opt/X11/lib" > export PATH="$(brew --prefix llvm)/bin:$PATH" > export PATH="$(brew --prefix bison)/bin:$PATH" > ./configure --without-freetype > make -j10 > tools/widl/widl -o ../vpinmame_i.h --nostdinc -Ldlls/\* -Iinclude -D__WINESRC__ -D_UCRT ../pinmame/src/win32com/VPinMAME.idl > > > Now with anything past 7.20 I’m getting: > > > configure: error: PE cross-compilation is required for ARM64, please install clang/llvm-dlltool/lld, or llvm-mingw. Hi, I’m not sure why you would be getting that error, can you post your config.log? Testing on Ventura, I’m able to configure with just bison and llvm from homebrew: export PATH=/opt/homebrew/opt/llvm/bin:/opt/homebrew/opt/bison/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin ./configure --without-freetype Also I don’t see an ‘llvm-mingw’ formula, where is that installed from? Brendan

Feb. 10, 2023

Re: Debugging channel weirdness

by Zebediah Figura

On 2/10/23 00:18, Rémi Bernon wrote: >> (1) Why does setting channel->flags affect performance at all? I'm >> thoroughly baffled by this one. >> >> (2) Why was this diff not applied in the first place? (Simple oversight?) >> >> (3) Why does __WINE_DBCL_INIT even exist, if its only purpose is to >> guard out a single assignment? >> >> --Zeb >> > > Probably to allow changing the selected channels dynamically, through > process monitor for instance. > I'm not sure which question this answers, but I don't think I understand it? winedbg and taskmgr just set the flags directly; they don't touch __WINE_DBCL_INIT, and I don't see why they'd need to.

Feb. 10, 2023

Re: Debugging channel weirdness

by Zebediah Figura

On 2/9/23 18:54, Zebediah Figura wrote: > (1) Why does setting channel->flags affect performance at all? I'm > thoroughly baffled by this one. Evan Tang provided me with the cluebat privately—it's because __WINE_DBCL_TRACE is always set, so we end up always calling __wine_dbg_header() [which will then discard the message]. So we probably really should fix this :x

Feb. 10, 2023

Compiling issues on macOS after 7.20 on ARM

by Jason Millard

Hello. I’m using parts of Wine (specifically the vbscript engine) while porting Visual Pinball to be cross platform. I have been using the WIDL utility extensively and it has worked great. I wanted to keep my patches up to date so I don’t fall behind, however I am having issues compiling wine after version 7.20. This was my typical compile: brew install llvm llvm-mingw git clone -b wine-7.20 git://source.winehq.org/git/wine.git git clone git(a)github.com:vpinball/pinmame.git cd wine export MACOSX_DEPLOYMENT_TARGET="10.14" export LDFLAGS="-Wl,-rpath,/opt/X11/lib" export PATH="$(brew --prefix llvm)/bin:$PATH" export PATH="$(brew --prefix bison)/bin:$PATH" ./configure --without-freetype make -j10 tools/widl/widl -o ../vpinmame_i.h --nostdinc -Ldlls/\* -Iinclude -D__WINESRC__ -D_UCRT ../pinmame/src/win32com/VPinMAME.idl Now with anything past 7.20 I’m getting: configure: error: PE cross-compilation is required for ARM64, please install clang/llvm-dlltool/lld, or llvm-mingw. Is there anyway to disable this? Thanks Jason

Feb. 10, 2023

Re: Debugging channel weirdness

by Rémi Bernon

On 2/10/23 01:54, Zebediah Figura wrote: > Hi all, > > I was running into some odd behaviour while debugging—specifically, I > found that specifying the d3d channel in WINEDEBUG was cutting my > performance in half, even when disabling logging, and even when it > should have been functionally identical to a run without the d3d channel > specified. > > I was able to "fix" this inconsistency with this diff: > > diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c > index 1bd8f900d22..f0e4b824918 100644 > --- a/dlls/ntdll/thread.c > +++ b/dlls/ntdll/thread.c > @@ -103,7 +103,11 @@ unsigned char __cdecl __wine_dbg_get_channel_flags( > struct __wine_debug_channel > { > pos = (min + max) / 2; > res = strcmp( channel->name, debug_options[pos].name ); > - if (!res) return debug_options[pos].flags; > + if (!res) > + { > + if (channel->flags & (1 << __WINE_DBCL_INIT)) > channel->flags = debug_options[pos].flags; > + return debug_options[pos].flags; > + } > if (res < 0) max = pos - 1; > else min = pos + 1; > } > > > > Which makes sense to some degree, but leaves three questions unanswered, > which I was hoping someone might be able to cluebat me on: > > (1) Why does setting channel->flags affect performance at all? I'm > thoroughly baffled by this one. > > (2) Why was this diff not applied in the first place? (Simple oversight?) > > (3) Why does __WINE_DBCL_INIT even exist, if its only purpose is to > guard out a single assignment? > > --Zeb > Probably to allow changing the selected channels dynamically, through process monitor for instance. -- Rémi Bernon <rbernon(a)codeweavers.com>

Feb. 10, 2023

Debugging channel weirdness

by Zebediah Figura

Hi all, I was running into some odd behaviour while debugging—specifically, I found that specifying the d3d channel in WINEDEBUG was cutting my performance in half, even when disabling logging, and even when it should have been functionally identical to a run without the d3d channel specified. I was able to "fix" this inconsistency with this diff: diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c index 1bd8f900d22..f0e4b824918 100644 --- a/dlls/ntdll/thread.c +++ b/dlls/ntdll/thread.c @@ -103,7 +103,11 @@ unsigned char __cdecl __wine_dbg_get_channel_flags( struct __wine_debug_channel { pos = (min + max) / 2; res = strcmp( channel->name, debug_options[pos].name ); - if (!res) return debug_options[pos].flags; + if (!res) + { + if (channel->flags & (1 << __WINE_DBCL_INIT)) channel->flags = debug_options[pos].flags; + return debug_options[pos].flags; + } if (res < 0) max = pos - 1; else min = pos + 1; } Which makes sense to some degree, but leaves three questions unanswered, which I was hoping someone might be able to cluebat me on: (1) Why does setting channel->flags affect performance at all? I'm thoroughly baffled by this one. (2) Why was this diff not applied in the first place? (Simple oversight?) (3) Why does __WINE_DBCL_INIT even exist, if its only purpose is to guard out a single assignment? --Zeb

Feb. 10, 2023

Wine staging 8.1 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.1 (475 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * rpcrt4: Avoid implicit cast of interface pointer. * include: Add _XHR enum values * ntdll-Builtin_Prot (removed as PE conversion is complete) Added: * None Updated: * ntdll-Placeholders Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Feb. 3, 2023