- Wine-devel - list.winehq.org

Troubleshooting openSUSE's packaging process
by Alexander Leithner 03 Apr '25

03 Apr '25

Hi all, back in October [1] I asked for advice on building Winelib DLLs because I was unable to compile 64-bit DLLs on my openSUSE Tumbleweed machine. I've since opened bug 1231820 [2] on openSUSE's Bugzilla that has yet to be resolved (which I understand, given that developing Wine-only applications is pretty niche, I reckon). While I can now (with Wine 10.0 from openSUSE's repositories) compile 32-bit Winelib DLLs without having to explicitly specify the library search path, 64-bit DLLs still don't work. This is because the packages are missing the relevant archive files (*.a) for 64-bit ELF; that is, all the libraries (*.so) are present in /usr/lib64/wine/x86_64-unix, but the corresponding *.a files are not. I was trying to troubleshoot this earlier today but I'm now lost (since I cannot, for the life of me, reproduce the build process behaviour) and would be grateful for any discussion of what I might be misunderstanding/doing wrong or what might be going wrong with the packaging process. The first noteworthy observation is that the RPM spec file [3, see lines 367-449] excludes all archive files when the package built is not the "-devel" variant, which is fine, but only includes the i386-unix archives when "-devel" is built. That is probably an oversight, but not the main problem, I reckon. Namely: The x86_64-unix *.a files do not show up in the build logs [4] at all (Ctrl-F for "unix/libwinecrt0.a", for example). Even more, RPM itself complains that the files it should exclude are not found when building the non-devel variant of the package (Ctrl-F for "not found", messages around the 999s mark). This, to me, indicates that the files aren't even built. As can be seen in the logs, openSUSE uses the following ./configure command line to build 64-bit Wine: ../configure --host=x86_64-suse-linux --build=x86_64-suse-linux --program-prefix= [...] --with-x --with-wayland --with-gstreamer --enable-win64 --verbose (I've omitted prefix- and dir-related switches). I've built Wine from source with the following command line: ../configure [...] --build=x86_64-suse-linux --build=x86_64-suse-linux --enable-win64 (I've omitted --prefix only here). This produces an environment which can correctly build both 32-bit as well as 64-bit Winelib DLLs (without needing to set -L explicitly, as expected). I can see install-sh calls, as expected, for the *.a files in lib64/x86_64-unix, which are absent from the OBS build logs. My commandline generates lib64/x86_64-unix and lib64/x86_64-windows. On the other hand, the openSUSE build log for wine-devel-32bit [5] shows the i386-unix archive files being generated and installed. For 32-bit, they're using: ../configure --host=i586-suse-linux --build=i586-suse-linux --program-prefix= [...] --with-x --with-wayland --with-gstreamer --verbose Since I don't expect --with-x --with-wayland --with-gstreamer --verbose to change anything on whether archive files are built, how come the 64-bit build on OBS is not providing these *.a for x86_64-unix? I posted some more commandlines which don't seem to work correctly to the linked Bugzilla issue [2] back in December. I'm unsure if any of those I've tried there should be expected to produce correct results, so I'm focused on understanding of what's wrong with the 64-bit OBS build. Thanks for any insight, advice, pointers, or corrections you might have for me. Regards, Alexander Leithner [1]: https://list.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.org/th… [2]: https://bugzilla.opensuse.org/show_bug.cgi?id=1231820 [3]: https://build.opensuse.org/projects/openSUSE:Factory/packages/wine/files/wi… [4]: https://build.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/wi… [5]: https://build.opensuse.org/public/build/openSUSE:Factory/standard/i586/wine…

2 1

Question about `wineboot: Create section objects for known dlls' patch
by Mitch Wilkinson 03 Apr '25

03 Apr '25

2 1

Transition of power
by Alex Henrie 03 Apr '25

03 Apr '25

Loyal vintners and vintresses, It is necessary to call your attention to the current state of the regression leaderboard: Rémi Bernon is up to 20 regressions.[1] In an email dated 14 November 2024, our esteemed Principal Oenologist, Alexandre Julliard, stated:[2] > As with the regressions page, the goal should be to *not* be number one on the list. The plain meaning is that being Sommelier-in-Chief is a thankless job that no one in their right mind should aspire to. Nonetheless, it is an indisputable fact that Rémi's Julliard Rank is now 33% higher than Julliard himself.[3] (Before the Wine 10.0 code freeze Elizabeth Figura was the heir presumptive,[4] but her rising star has since fallen to third place.) Rémi has far and away proved his greater worthiness. Therefore, by law and custom, Alexandre must step down and make room for a new leader. A coronation will be held at the next WineConf, with light refreshments following. Sincerely, The High Council of the International Monarchist League [1] https://source.winehq.org/regressions [2] https://list.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.org/th… [3] https://list.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.org/th… [4] https://web.archive.org/web/20240915073049/https://source.winehq.org/regres…

3 4

Wine staging 10.4 release
by Alistair Leslie-Hughes 22 Mar '25

22 Mar '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.4 (341 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * d3dx9: Implement d3dx_effect_SetRawValue. * d3dx9/tests: Implement tests for d3dx_effect_SetRawValue(). * winex11.drv: Don't use MWM_DECOR_RESIZEH, window resizing is controlled by MWM_FUNC_RESIZE. * winex11.drv: Don't add MWM_DECOR_BORDER to windows without a caption. * winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow. Removed (No longer required). * None Added: * msxml3: Correct regression when looping element properties. Updated: * vkd3d-latest * Staging 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.

1 0

Re: [PATCH 1/4] selftests: ntsync: fix the wrong condition in wake_all
by Elizabeth Figura 15 Mar '25

15 Mar '25

On Saturday, 15 March 2025 04:39:46 CDT Dan Carpenter wrote: > On Fri, Mar 14, 2025 at 05:13:50PM -0500, Elizabeth Figura wrote: > > On Friday, 14 March 2025 05:14:30 CDT Su Hui wrote: > > > On 2025/3/14 17:21, Dan Carpenter wrote: > > > > On Fri, Mar 14, 2025 at 03:14:51PM +0800, Su Hui wrote: > > > >> When 'manual=false' and 'signaled=true', then expected value when using > > > >> NTSYNC_IOC_CREATE_EVENT should be greater than zero. Fix this typo error. > > > >> > > > >> Signed-off-by: Su Hui<suhui(a)nfschina.com> > > > >> --- > > > >> tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- > > > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > >> > > > >> diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > > > >> index 3aad311574c4..bfb6fad653d0 100644 > > > >> --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > > > >> +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > > > >> @@ -968,7 +968,7 @@ TEST(wake_all) > > > >> auto_event_args.manual = false; > > > >> auto_event_args.signaled = true; > > > >> objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); > > > >> - EXPECT_EQ(0, objs[3]); > > > >> + EXPECT_LE(0, objs[3]); > > > > It's kind of weird how these macros put the constant on the left. > > > > It returns an "fd" on success. So this look reasonable. It probably > > > > won't return the zero fd so we could probably check EXPECT_LT()? > > > Agreed, there are about 29 items that can be changed to EXPECT_LT(). > > > I can send a v2 patchset with this change if there is no more other > > > suggestions. > > > > I personally think it looks wrong to use EXPECT_LT(), but I'll certainly > > defer to a higher maintainer on this point. > > I'm not sure I understand what you are saying. Are you saying that we > should allow zero as an expected file descriptor here? I don't have > strong feelings about that either way. Yes, my apologies for the ambiguous wording. That is, EXPECT_LE looks more correct to me than EXPECT_LT per se. > Putting variables on the right, Yoda speak is. Unnatural is. Yes, I certainly agree with this. I wrote it this way in the first place because I was following some other example, I forget which. > I did a git grep and the KUNIT_EXPECT_LT() just calls the parameters > left and right instead of "expected" and "seen". Expected is wrong > for LT because we expect it to be != to the expected value. It's > the opposite. We're expecting the unexpected! It would be better > to just call them left and right. > > regards, > dan carpenter >

1 0

Re: [PATCH 1/4] selftests: ntsync: fix the wrong condition in wake_all
by Elizabeth Figura 14 Mar '25

14 Mar '25

On Friday, 14 March 2025 05:14:30 CDT Su Hui wrote: > On 2025/3/14 17:21, Dan Carpenter wrote: > > On Fri, Mar 14, 2025 at 03:14:51PM +0800, Su Hui wrote: > >> When 'manual=false' and 'signaled=true', then expected value when using > >> NTSYNC_IOC_CREATE_EVENT should be greater than zero. Fix this typo error. > >> > >> Signed-off-by: Su Hui<suhui(a)nfschina.com> > >> --- > >> tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > >> index 3aad311574c4..bfb6fad653d0 100644 > >> --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > >> +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > >> @@ -968,7 +968,7 @@ TEST(wake_all) > >> auto_event_args.manual = false; > >> auto_event_args.signaled = true; > >> objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); > >> - EXPECT_EQ(0, objs[3]); > >> + EXPECT_LE(0, objs[3]); > > It's kind of weird how these macros put the constant on the left. > > It returns an "fd" on success. So this look reasonable. It probably > > won't return the zero fd so we could probably check EXPECT_LT()? > Agreed, there are about 29 items that can be changed to EXPECT_LT(). > I can send a v2 patchset with this change if there is no more other > suggestions. I personally think it looks wrong to use EXPECT_LT(), but I'll certainly defer to a higher maintainer on this point.

1 0

Re: [PATCH 4/4] docs: ntsync: update NTSYNC_IOC_*
by Elizabeth Figura 14 Mar '25

14 Mar '25

On Friday, 14 March 2025 02:14:54 CDT Su Hui wrote: > Some macros in the document do not match the code and the header files, > correct these macros according to the definitions in the code. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > Documentation/userspace-api/ntsync.rst | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/Documentation/userspace-api/ntsync.rst b/Documentation/userspace-api/ntsync.rst > index 25e7c4aef968..969774bf4c60 100644 > --- a/Documentation/userspace-api/ntsync.rst > +++ b/Documentation/userspace-api/ntsync.rst > @@ -152,9 +152,9 @@ The ioctls on the device file are as follows: > > The ioctls on the individual objects are as follows: > > -.. c:macro:: NTSYNC_IOC_SEM_POST > +.. c:macro:: NTSYNC_IOC_SEM_RELEASE > > - Post to a semaphore object. Takes a pointer to a 32-bit integer, > + Release a semaphore object. Takes a pointer to a 32-bit integer, > which on input holds the count to be added to the semaphore, and on > output contains its previous count. > > @@ -186,7 +186,7 @@ The ioctls on the individual objects are as follows: > unowned and signaled, and eligible threads waiting on it will be > woken as appropriate. > > -.. c:macro:: NTSYNC_IOC_SET_EVENT > +.. c:macro:: NTSYNC_IOC_EVENT_SET > > Signal an event object. Takes a pointer to a 32-bit integer, which on > output contains the previous state of the event. > @@ -194,12 +194,12 @@ The ioctls on the individual objects are as follows: > Eligible threads will be woken, and auto-reset events will be > designaled appropriately. > > -.. c:macro:: NTSYNC_IOC_RESET_EVENT > +.. c:macro:: NTSYNC_IOC_EVENT_RESET > > Designal an event object. Takes a pointer to a 32-bit integer, which > on output contains the previous state of the event. > > -.. c:macro:: NTSYNC_IOC_PULSE_EVENT > +.. c:macro:: NTSYNC_IOC_EVENT_PULSE > > Wake threads waiting on an event object while leaving it in an > unsignaled state. Takes a pointer to a 32-bit integer, which on > @@ -213,7 +213,7 @@ The ioctls on the individual objects are as follows: > afterwards, and a simultaneous read operation will always report the > event as unsignaled. > > -.. c:macro:: NTSYNC_IOC_READ_SEM > +.. c:macro:: NTSYNC_IOC_SEM_READ > > Read the current state of a semaphore object. Takes a pointer to > struct :c:type:`ntsync_sem_args`, which is used as follows: > @@ -225,7 +225,7 @@ The ioctls on the individual objects are as follows: > * - ``max`` > - On output, contains the maximum count of the semaphore. > > -.. c:macro:: NTSYNC_IOC_READ_MUTEX > +.. c:macro:: NTSYNC_IOC_MUTEX_READ > > Read the current state of a mutex object. Takes a pointer to struct > :c:type:`ntsync_mutex_args`, which is used as follows: > @@ -242,7 +242,7 @@ The ioctls on the individual objects are as follows: > ``EOWNERDEAD``. In this case, ``count`` and ``owner`` are set to > zero. > > -.. c:macro:: NTSYNC_IOC_READ_EVENT > +.. c:macro:: NTSYNC_IOC_EVENT_READ > > Read the current state of an event object. Takes a pointer to struct > :c:type:`ntsync_event_args`, which is used as follows: > @@ -255,7 +255,7 @@ The ioctls on the individual objects are as follows: > - On output, contains 1 if the event is a manual-reset event, > and 0 otherwise. > > -.. c:macro:: NTSYNC_IOC_KILL_OWNER > +.. c:macro:: NTSYNC_IOC_MUTEX_KILL > > Mark a mutex as unowned and abandoned if it is owned by the given > owner. Takes an input-only pointer to a 32-bit integer denoting the > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

1 0

Re: [PATCH 3/4] selftests: ntsync: update config
by Elizabeth Figura 14 Mar '25

14 Mar '25

On Friday, 14 March 2025 02:14:53 CDT Su Hui wrote: > ntsync should be tested when CONFIG_NTSYNC is setting rather than > CONFIG_WINESYNC, correct this. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > tools/testing/selftests/drivers/ntsync/config | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/drivers/ntsync/config b/tools/testing/selftests/drivers/ntsync/config > index 60539c826d06..0aa68de147af 100644 > --- a/tools/testing/selftests/drivers/ntsync/config > +++ b/tools/testing/selftests/drivers/ntsync/config > @@ -1 +1 @@ > -CONFIG_WINESYNC=y > +CONFIG_NTSYNC=y > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

1 0

Re: [PATCH 2/4] selftests: ntsync: avoid possible overflow in 32-bit machine
by Elizabeth Figura 14 Mar '25

14 Mar '25

On Friday, 14 March 2025 02:14:52 CDT Su Hui wrote: > When using '-m32' flag to compile this test with gcc, there are some > errors when running test: > > ntsync.c:785:wake_any:Expected ETIMEDOUT (110) == ret (0) > ntsync.c:823:wake_any:Expected (1) (1) == __count (0) > ... > FAILED: 7 / 11 tests passed. > Totals: pass:7 fail:4 xfail:0 xpass:0 skip:0 error:0 > > There is an overflow about 'timeout'. 'timespec->tv_sec' is 4 bytes in > 32-bit machine. And 'timeout.tv_sec * 1000000000' causing the overflow > problem, adding a cast to avoid this problem. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > tools/testing/selftests/drivers/ntsync/ntsync.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > index bfb6fad653d0..ded83dc58e6b 100644 > --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > @@ -103,7 +103,7 @@ static int wait_objs(int fd, unsigned long request, __u32 count, > > clock_gettime(CLOCK_MONOTONIC, &timeout); > > - args.timeout = timeout.tv_sec * 1000000000 + timeout.tv_nsec; > + args.timeout = (__u64)timeout.tv_sec * 1000000000 + timeout.tv_nsec; > args.count = count; > args.objs = (uintptr_t)objs; > args.owner = owner; > @@ -729,7 +729,7 @@ static __u64 get_abs_timeout(unsigned int ms) > { > struct timespec timeout; > clock_gettime(CLOCK_MONOTONIC, &timeout); > - return (timeout.tv_sec * 1000000000) + timeout.tv_nsec + (ms * 1000000); > + return ((__u64)timeout.tv_sec * 1000000000) + timeout.tv_nsec + (ms * 1000000); > } > > static int wait_for_thread(pthread_t thread, unsigned int ms) > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

1 0

Re: [PATCH 1/4] selftests: ntsync: fix the wrong condition in wake_all
by Elizabeth Figura 14 Mar '25

14 Mar '25

On Friday, 14 March 2025 02:14:51 CDT Su Hui wrote: > When 'manual=false' and 'signaled=true', then expected value when using > NTSYNC_IOC_CREATE_EVENT should be greater than zero. Fix this typo error. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > index 3aad311574c4..bfb6fad653d0 100644 > --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > @@ -968,7 +968,7 @@ TEST(wake_all) > auto_event_args.manual = false; > auto_event_args.signaled = true; > objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); > - EXPECT_EQ(0, objs[3]); > + EXPECT_LE(0, objs[3]); > > wait_args.timeout = get_abs_timeout(1000); > wait_args.objs = (uintptr_t)objs; > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

1 0