wine-devel

wine-devel@winehq.org

84467 discussions

Apple Silicon compilation
by robert lippmann 10 Apr '25

10 Apr '25

Hi all, I tried to update the wiki to document how to compile Wine on Apple Silicon, but I’m not sure if it went through. Basically, you need to add lld (which pulls in llvm) in addition to the other build dependencies So: brew install lld Then: PATH=`brew —prefix llvm`/bin:`brew —prefix bison`/bin:$PATH Then everything compiles. You probably don’t even need Xcode. And you probably should have Rosetta2 installed. I haven’t actually been able to get it to run yet, though… — Rob

5 8

Wine staging 10.5 release
by Alistair Leslie-Hughes 06 Apr '25

06 Apr '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.5 (336 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * winex11.drv: Add support for _NET_ACTIVE_WINDOW. * user32: Before asking a WM to activate a window make sure that the window is in foreground and not minimized. * shell32: Added stub for IEnumObjects interface. * shell32: Added stub for IObjectCollection interface. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * ntdll-Syscall_Emulation * ntdll-ForceBottomUpAlloc 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: Troubleshooting openSUSE's packaging process
by Alexander Leithner 05 Apr '25

05 Apr '25

Am 04.04.25 um 15:44 schrieb Alexandre Julliard: > Alexander Leithner <aleithner(a)level101.at> writes: >> Shouldn't GCC provide support for -mabi=ms out of the box? > > Yes, there must be something else going on. Is the config.log file > available? OK, I've managed to extract config.log from a local OBS build. The section relevant to -mabi=ms reads: configure:20674: checking for working -mabi=ms configure:20693: gcc -m64 -c -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -mabi=ms conftest.c >&5 conftest.c: In function 'a': conftest.c:165:79: error: control reaches end of non-void function [-Werror=return-type] 165 | int a(int b, ...) { __builtin_ms_va_list list; __builtin_ms_va_start(list,b); } | ^ cc1: some warnings being treated as errors configure:20693: $? = 1 Indeed, the build script on OBS exports a bunch of additional flags before configuring Wine as seen above, including setting -Werror=return-type. Running configure with CFLAGS='-Werror=return-type ' also is enough to reproduce OBS' config.log output locally on my machine. Is this a bug in -mabi=ms detection or should OBS not set -Werror=return-type? As a side note, OBS also enables Fortify. Isn't this subsequently disabled by configure anyway? If so, I imagine OBS could just not enable it in the first place, right? Thanks for your help! Best, Alexander Leithner

2 2

Wine with 64 bit prefix and databases
by Ilya Sokolov 04 Apr '25

04 Apr '25

Hello It may be not the best place to send the question to this list, but I have tried it on different forums and got no answer. I have a windows C++ application, which should be run in x64 environment due to a memory consumption. One of users of the application requires it run on Linux. The application is rather big and uses some windows-specific features, like COM interfaces, so it would be hard to make it cross-platform. Therefore it was decided to try running the application under Wine. The application uses an MS Access database , which contains some parameters and settings for calculations. The application successfully runs under WINE until it tries to connect to the database, because there is no ADO data provider available. I have tried installing MDAC via winetricks, downloading and installing Access Runtime 2010 and 2016, but all with ho success. Could you tell me what is the proper way of setting up the access ADO driver in WINE in x64? If it is not possible now, could you tell me if any database works on wine in 64 bit prefix, so I will change the database type in the application. Thank you! Best Regards, Ilia Sokolov

2 1

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@winehq.org/thre… [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@winehq.org/thre… [3] https://list.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/thre… [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

← Newer
1
2
3
4
5
6
7
...
8447
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel