April 2025 - Wine-Devel - list.winehq.org

Re: Troubleshooting openSUSE's packaging process

by Alexander Leithner

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

April 5, 2025

Re: Wine with 64 bit prefix and databases

by Owen Rudge

On 04/04/2025 14:06, Ilya Sokolov wrote: > 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. Wine's ADO support is still somewhat rudimentary, and you would still require the separate Access runtime. As far as I know, the MDAC installed by winetricks is 32-bit only; I don't think Microsoft ever released a 64-bit redistributable. Unless you can switch to using ODBC instead (which is better supported in Wine), you probably won't have much success even if you used a different database driver, without more work being done on our ADO implementation. Owen

April 4, 2025

Wine with 64 bit prefix and databases

by Ilya Sokolov

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

April 4, 2025

Re: Troubleshooting openSUSE's packaging process

by Alexandre Julliard

Alexander Leithner <aleithner(a)level101.at> writes: > 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? It looks like the compiler doesn't support -mabi=ms, or it's not detected correctly: checking for working -mabi=ms... no The default sysv ABI is not compatible on x86-64, so Unix libraries can't be built without -mabi=ms. On i386 the ABIs are compatible so that option is not required. -- Alexandre Julliard julliard(a)winehq.org

April 3, 2025

Troubleshooting openSUSE's packaging process

by Alexander Leithner

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…

April 3, 2025

Re: Question about `wineboot: Create section objects for known dlls' patch

by Alexandre Julliard

Mitch Wilkinson <foo.ami(a)yandex.com> writes: > I have a question about patch 81ea1e7a20c (wineboot: Create section objects for known dlls., 2025-03-31) recently landed to `Wine > development'. > > Do I understand correctly, that create_known_dlls() function initializes (and then clears) internal list of KnownDLLs, creates NT section for each > that KnownDLL and its import dependency and then closes all those sections? Thus, effectively create_known_dlls() does nothing -- the dlls list > is on its stack anyway, NT sections are created and almost immediately closed. What the purpose of create_known_dlls() function? May be I > missed something, sorry, but please explain what happens there. The section objects are created with OBJ_PERMANENT, so closing them doesn't delete them. -- Alexandre Julliard julliard(a)winehq.org

April 3, 2025

Question about `wineboot: Create section objects for known dlls' patch

by Mitch Wilkinson

April 3, 2025

Re: Transition of power

by Alex Henrie

On Wed, Apr 2, 2025 at 12:47 AM Rémi Bernon <rbernon(a)codeweavers.com> wrote: > > On 4/1/25 08:00, Alex Henrie wrote: > > 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… > > > > I'm impressed by the effort to set this up and glad this was all an > April Fool's Day prank. We can close all the bugs now, right? Sure, we can close all the bugs (and obviously the regression leaderboard went down yesterday because we won't be needing it for the foreseeable future), but you're not getting out of the coronation ;-)

April 3, 2025

Re: Transition of power

by Rémi Bernon

On 4/2/25 08:47, Rémi Bernon wrote: > On 4/1/25 08:00, Alex Henrie wrote: >> 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/thread/QOYOIJHTGVUDCFZF2MQ7KFT6A7BFNS7Z/ >> [3] https://list.winehq.org/mailman3/hyperkitty/list/wine- >> devel(a)winehq.org/thread/7CDUAWL5DWFKXKIZL2WGWU7DNFFR3IP6/ >> [4] https://web.archive.org/web/20240915073049/https:// >> source.winehq.org/regressions > > I'm impressed by the effort to set this up and glad this was all an > April Fool's Day prank. We can close all the bugs now, right? > That's exactly what I meant, thanks! -- Rémi Bernon <rbernon(a)codeweavers.com>

April 2, 2025

Re: Transition of power

by Rémi Bernon

On 4/1/25 08:00, Alex Henrie wrote: > 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… > I'm impressed by the effort to set this up and glad this was all an April Fool's Day prank. We can close all the bugs now, right? -- Rémi Bernon <rbernon(a)codeweavers.com>

April 2, 2025