October 2024 - Wine-Devel - list.winehq.org

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications

by Derek Lesho

On 10/19/24 00:47, Faith Ekstrand wrote: > The timing here isn't great, unfortunately. I'd love to contribute > more to the discussion but I'm going on leave starting next week until > mid-Febuary so I won't be able to participate much until then. I'll > try to leave a few thoughts, though. Thanks for the comments! I'll actually also be quite busy until then (Uni), but maybe by February they'll be a consensus on the path forward 😀. > > On Fri, Oct 18, 2024 at 5:10 PM Derek Lesho <dlesho(a)codeweavers.com> > wrote: > > Hey everyone 👋, > > I'm Derek from the Wine project, and wanted to start a discussion > with > y'all about potentially extending the Mesa OGL drivers to help us > with a > functionality gap we're facing. > > Problem Space: > > In the last few years Wine's support for running 32-bit windows > apps in > a 64-bit host environment (wow64) has almost reached feature > completion, > but there remains a pain point with OpenGL applications: Namely that > Wine can't return a 64-bit GL implementation's buffer mappings to > a 32 > bit application when the address is outside of the 32-bit range. > > Currently, we have a workaround that will copy any changes to the > mapping back to the host upon glBufferUnmap, but this of course is > slow > when the implementation directly returns mapped memory, and > doesn't work > for GL_PERSISTENT_BIT, where directly mapped memory is required. > > A few years ago we also faced this problem with Vulkan's, which was > solved through the VK_EXT_map_memory_placed extension Faith drafted, > allowing us to use our Wine-internal allocator to provide the > pages the > driver maps to. I'm now wondering if an GL equivalent would also > be seen > as feasible amongst the devs here. > > Proposed solution: > > As the GL backend handles host mapping in its own code, only giving > suballocations from its mappings back to the App, the problem is a > little bit less straight forward in comparison to our Vulkan > solution: > If we just allowed the application to set its own placed mapping when > calling glMapBuffer, the driver might then have to handle moving > buffers > out of already mapped ranges, and would lose control over its own > memory > management schemes. > > Therefore, I propose a GL extension that allows the GL client to > provide > a mapping and unmapping callback to the implementation, to be used > whenever the driver needs to perform such operations. This way the > driver remains in full control of its memory management affairs, > and the > amount of work for an implementation as well as potential for bugs is > kept minimal. I've written a draft implementation in Zink using > map_memory_placed [1] and a corresponding Wine MR utilizing it > [2], and > would be curious to hear your thoughts. I don't have experience in > the > Mesa codebase, so I apologize if the branch is a tad messy. > > It's an interesting approach, to be sure. I don't mean that as a bad > or good thing as I haven't given this enough thought with GL in mind > to have a better, more well thought out plan. > > The most obvious issue that jumps out to me is that we really want > that callback to be set before anyone ever maps a buffer that might > possibly get exposed to the client and we want it to never change. If > this were Vulkan, we'd have you provide it at vkCreateDevice() time. > But this is GL where everybody loves a big mutable state object. If we > do go with callbacks (and it's still not 100% clear to me what the > right choice is), we'd want them to be somehow set-once and set before > any buffers are created. I'm not 100% sure how you'd spec that or how > we'd enforce it. There may be some precedent for this somewhere in GL > (no_error, maybe?) but I'm not sure. Right, in the case of Zink I was just lucky it doesn't happen to map anything upon context creation. If I understand what you mean by using a no_error like approach correctly, I think that should definitely work, I think we would then just somewhat-awkwardly want to pass through the callback address as two context attributes, one for the lower and one for the higher part of the address. However, even if we find a way to make the mapping callback's global on the context level, that then still requires from the driver that they relegate mappings in these contexts to dedicated memory pools. This might be desired, in order to allow other GL clients in the process to continue using the full 64-bit address space, although in practice I don't think Wine uses any libraries that create GL contexts (*other than potentially GStreamer which we are moving away from). If we just want to keep it simple and workaround the GL context, maybe Wine could just export its allocator in ntdll.so in a way that where Mesa could then directly call it when present. That way we could even avoid the need for a GL extension that will at the end of the day probably only be used by Wine, plus avoid the awkwardness of not wanting to map anything in the driver until we get mapping callback. > > The other question that comes to mind is when exactly we'd be expected > to use these things. Obviously, we need to do so for any map that may > be exposed to the client. However, it's not always easy to do that > because you don't know at buffer create time whether or not it will be > persistently mapped. A driver is likely to have all sorts of internal > mappings for things and, while those can come from one of those > ranges, it'll burn more of that precious 32-bit address space than > needed. This gets worse when you take sub-allocation into account. If > we're okay with all buffer mappings going down the client-request path > then it's probably okay. The driver just might need an extra bit in > its buffer cache key. Yeah, it would definitely be a nice bonus to the new path if drivers kept their internal mappings outside of 32-bit address space, but as far as I can see I don't think this affects our choice of interface, as mesa should be able to handle client visible buffers differently from driver-internal ones without the help of the client. > > I'm also sitting here trying to come up with some plan that would let > us do this more like Vulkan and I'm having trouble coming up with one > that works. GL has no concept of "create time". We could theoretically > do something where we flush everything, copy the data to a new > placed-mappable buffer and then continue on but that's gonna suck. Yeah, and then you also still have to define how you create this new placed-mappable buffer, and there isn't really a small-neat solution for this. You could define a GL_OUT_OF_PLACED_MEMORY error in glMapBuffer, and then have another entry point by which the app feeds the driver pages, but then you run into the problem of unmapping, which as far as I can see is often performed asynchronously. > > I think that's all that comes to mind immediately. As I said at the > top, I'm happy to talk more in a few months. Best of luck until then! > > ~Faith > > In theory, the only requirement from drivers from the extension > would be > that glMapBuffer always return a pointer from within a page allocated > through the provided callbacks, so that it can be guaranteed to be > positioned within the required address space. Wine would then use > it's > existing workaround for other types of buffers, but as Mesa seems to > often return directly mapped buffers in other cases as well, Wine > could > also avoid the slowdown that comes with copying in these cases as > well. > > Why not use Zink?: > > There's also a proposal to use a 32-bit PE build of Zink in Wine > bypassing the need for an extension; I brought this to discussion in > this Wine-Devel thread last week [3], which has some arguments > against > this approach. > > > For cases where Zink is being used on the host (this is the current > plan for Nouveau going forward), doing Zink in Windows may not be a > bad idea. However, I agree that it may not be the best idea to rely on > that plan. > > If any of you have thoughts, concerns, or questions about this > potential > approach, please let me know, thanks! > > 1: > https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation > > 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663 > > 3: https://marc.info/?t=172883260300002&r=1&w=2 > <https://marc.info/?t=172883260300002&r=1&w=2> >

Oct. 19, 2024

Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications

by Derek Lesho

Hey everyone 👋, I'm Derek from the Wine project, and wanted to start a discussion with y'all about potentially extending the Mesa OGL drivers to help us with a functionality gap we're facing. Problem Space: In the last few years Wine's support for running 32-bit windows apps in a 64-bit host environment (wow64) has almost reached feature completion, but there remains a pain point with OpenGL applications: Namely that Wine can't return a 64-bit GL implementation's buffer mappings to a 32 bit application when the address is outside of the 32-bit range. Currently, we have a workaround that will copy any changes to the mapping back to the host upon glBufferUnmap, but this of course is slow when the implementation directly returns mapped memory, and doesn't work for GL_PERSISTENT_BIT, where directly mapped memory is required. A few years ago we also faced this problem with Vulkan's, which was solved through the VK_EXT_map_memory_placed extension Faith drafted, allowing us to use our Wine-internal allocator to provide the pages the driver maps to. I'm now wondering if an GL equivalent would also be seen as feasible amongst the devs here. Proposed solution: As the GL backend handles host mapping in its own code, only giving suballocations from its mappings back to the App, the problem is a little bit less straight forward in comparison to our Vulkan solution: If we just allowed the application to set its own placed mapping when calling glMapBuffer, the driver might then have to handle moving buffers out of already mapped ranges, and would lose control over its own memory management schemes. Therefore, I propose a GL extension that allows the GL client to provide a mapping and unmapping callback to the implementation, to be used whenever the driver needs to perform such operations. This way the driver remains in full control of its memory management affairs, and the amount of work for an implementation as well as potential for bugs is kept minimal. I've written a draft implementation in Zink using map_memory_placed [1] and a corresponding Wine MR utilizing it [2], and would be curious to hear your thoughts. I don't have experience in the Mesa codebase, so I apologize if the branch is a tad messy. In theory, the only requirement from drivers from the extension would be that glMapBuffer always return a pointer from within a page allocated through the provided callbacks, so that it can be guaranteed to be positioned within the required address space. Wine would then use it's existing workaround for other types of buffers, but as Mesa seems to often return directly mapped buffers in other cases as well, Wine could also avoid the slowdown that comes with copying in these cases as well. Why not use Zink?: There's also a proposal to use a 32-bit PE build of Zink in Wine bypassing the need for an extension; I brought this to discussion in this Wine-Devel thread last week [3], which has some arguments against this approach. If any of you have thoughts, concerns, or questions about this potential approach, please let me know, thanks! 1: https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663 3: https://marc.info/?t=172883260300002&r=1&w=2

Oct. 18, 2024

Wine staging 9.20 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 9.20 (357 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None. Removed (No longer required). * None Added: * [33190]: win32u - Fix rendering of the rotated and scaled text. Updated: * vkd3d-latest 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.

Oct. 18, 2024

Re: Trouble compiling Winelib DLL for 64-bit on OpenSUSE

by Stefan Dösinger

Am Donnerstag, 17. Oktober 2024, 23:25:37 GMT+3 schrieb Krzysztof Bogacki: > On Thursday, October 17th, 2024 at 20:23, Alexander Leithner >> I've read about this transition. Just out of curiousity, would it be >> possible/feasible for external DLL projects (like mine) to transition >> too, especially if they need to call native Linux libraries? (Probably >> not, since we can't link between ELF and PE, right?) >> >> Or will Winelib and the current build/call process be supported for the >> forseeable future? > Hi, I might bring an answer to your first question. Regarding question 2, I don't think we have any plans to deliberately break the old all-in-one .dll.so binaries. It is quite likely that this functionality will bitrot over time though. Also the functionality that the PE/unix split was introduced for won't be available that way: * Make DRM systems happy that compare the on-disk DLL to the loaded image * x86 on arm emulation * 32 bit Windows programs with 64 bit Wine * Full %gs access on macos * Similar to the previous thing, support for aarch64 Windows binaries, use the x19 registers for thread local storage So if your library is something that should be useful for the wider community then the new style is certainly the way to go.

Oct. 18, 2024

Re: Trouble compiling Winelib DLL for 64-bit on OpenSUSE

by Krzysztof Bogacki

On Thursday, October 17th, 2024 at 20:23, Alexander Leithner <aleithner(a)level101.at> wrote: > > > Hi Stefan, > > thanks a lot for your advice! > > Am 15.10.24 um 22:42 schrieb Stefan Dösinger: > > > Wine itself has transitioned to a more formal (fake-)syscall and unix call > > interface to switch between the Windows and the Linux side. I think there are > > no DLLs left in Wine any more that have the old hybrid PE and ELF linkage. > > > > I've read about this transition. Just out of curiousity, would it be > possible/feasible for external DLL projects (like mine) to transition > too, especially if they need to call native Linux libraries? (Probably > not, since we can't link between ELF and PE, right?) > > Or will Winelib and the current build/call process be supported for the > forseeable future? > > > > winegcc -m32 -L/usr/lib64/wine/i386-unix -shared -o myproject.dll > > > myproject_main.c myproject.spec > > > > Does the 32 bit DLL link without the -L path? You shouldn't need it, winegcc > > and winebuild should know their installation path. > > > > No. Winegcc as provided by openSUSE doesn't find the right path. > > > It is quite likely a bug on openSUSE's side. They probably didn't even test > > winegcc with the wine-devel packages, as it is a pretty rare case that someone > > needs it. > > > > Since I also gather from your question that -L shouldn't be required, > I'll think about filing a bug report with openSUSE, as was suggested on > my original openSUSE Forums post if I should discover that I was doing > everything correctly. > > > I think your best choice would be to build wine from source and install it to > > a custom prefix in your home directory. Hopefully the wine-devel packages pull > > in the right headers etc to make it easy to do. > > > > Absolutely, building Wine from source has fixed the issue. > Interestingly, I only get the following folder structure > > prefix/lib64/wine > +- i386-windows > +- x86_64-unix > +- x86_64-windows > > with archive files present in all of these directories, though both > 32-bit and 64-bit versions of my DLL now compile fine (i.e. I correctly > get a 32-bit/64-bit ELF object). Since it works, I assume this is the > expected behaviour. > > Though I haven't been able to test the 64-bit binary yet, since the > 32-bit version works after compiling with my self-built winegcc, I > assume that I'm now able to build both versions correctly. > > I don't have to pass -L to my self-built winegcc, therefore everything > works as it should on Wine's side, as far as I can judge that. > > Thanks again and best regards, > Alexander Leithner > > > Hi, I might bring an answer to your first question. Yes, it is possible for external projects to use the new unixcall interface, which I took advantage of in my own project, wine-nvml[1]. With this approach you need to build PE and ELF parts separately then have PE one call the other only through Wine's syscall thunk/dispatcher. This allowed me to expose Windows-side equivalents of NVML functions via PE nvml.dll, where implementations of most entrypoints pack their arguments into dedicated structs, call ELF nvml.so with appropriate unixcall number, and there they are forwarded to NVIDIA's own libnvidia-ml.so before the result is returned via the same struct to the calling application. This however comes with some limitations, with the major one being: it's very hard to call PE side from Unix side. But some (if not most) libraries won't need this at all. [2] and [3] are nice posts that describe this interface in greater detail but if you're interested in some real world example then feel free to take a look at my repository. You'll have to run the generator (make_nvml) to see the actual C code. Regards, Krzysztof Bogacki [1]: https://github.com/Saancreed/wine-nvml [2]: https://blog.hiler.eu/wine-pe-to-unix/ [3]: https://blog.hiler.eu/wine-pe-to-unix-update/

Oct. 17, 2024

Re: Trouble compiling Winelib DLL for 64-bit on OpenSUSE

by Alexander Leithner

Hi Stefan, thanks a lot for your advice! Am 15.10.24 um 22:42 schrieb Stefan Dösinger: > Wine itself has transitioned to a more formal (fake-)syscall and unix call > interface to switch between the Windows and the Linux side. I think there are > no DLLs left in Wine any more that have the old hybrid PE and ELF linkage. I've read about this transition. Just out of curiousity, would it be possible/feasible for external DLL projects (like mine) to transition too, especially if they need to call native Linux libraries? (Probably not, since we can't link between ELF and PE, right?) Or will Winelib and the current build/call process be supported for the forseeable future? >> winegcc -m32 -L/usr/lib64/wine/i386-unix -shared -o myproject.dll >> myproject_main.c myproject.spec > > Does the 32 bit DLL link without the -L path? You shouldn't need it, winegcc > and winebuild should know their installation path. No. Winegcc as provided by openSUSE doesn't find the right path. > It is quite likely a bug on openSUSE's side. They probably didn't even test > winegcc with the wine-devel packages, as it is a pretty rare case that someone > needs it. Since I also gather from your question that -L shouldn't be required, I'll think about filing a bug report with openSUSE, as was suggested on my original openSUSE Forums post if I should discover that I was doing everything correctly. > I think your best choice would be to build wine from source and install it to > a custom prefix in your home directory. Hopefully the wine-devel packages pull > in the right headers etc to make it easy to do. Absolutely, building Wine from source has fixed the issue. Interestingly, I only get the following folder structure prefix/lib64/wine +- i386-windows +- x86_64-unix +- x86_64-windows with archive files present in all of these directories, though both 32-bit and 64-bit versions of my DLL now compile fine (i.e. I correctly get a 32-bit/64-bit ELF object). Since it works, I assume this is the expected behaviour. Though I haven't been able to test the 64-bit binary yet, since the 32-bit version works after compiling with my self-built winegcc, I assume that I'm now able to build both versions correctly. I don't have to pass -L to my self-built winegcc, therefore everything works as it should on Wine's side, as far as I can judge that. Thanks again and best regards, Alexander Leithner

Oct. 17, 2024

Re: Trouble compiling Winelib DLL for 64-bit on OpenSUSE

by David Kahurani

On Tue, Oct 15, 2024 at 11:43 PM Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Hello Alexander, > > Am Dienstag, 15. Oktober 2024, 15:18:57 GMT+3 schrieb > aleithner(a)level101.at: > > I have previously asked about the problem I'm describing below on > openSUSE's > > forums [1], StackOverflow [2] and Wine's forums [3], where dimesio told > me > > that I could try to ask here. If this is the wrong place to ask, I > > apologise. > > The mailing ist is the right place to ask :-) > If you post as bug on bugzilla, someone might help :-) > > I'll try to answer some of your questions below, but I am not much of a > winelib expert and sadly winelib is getting relatively little love. In my > quick test building a 32 and 64 bit .dll.so worked, but I would not be > surprised if there are bugs. > > Wine itself has transitioned to a more formal (fake-)syscall and unix call > interface to switch between the Windows and the Linux side. I think there > are > no DLLs left in Wine any more that have the old hybrid PE and ELF linkage. > > > winegcc -m32 -L/usr/lib64/wine/i386-unix -shared -o myproject.dll > > myproject_main.c myproject.spec > > Does the 32 bit DLL link without the -L path? You shouldn't need it, > winegcc > and winebuild should know their installation path. > > > As I've discovered, openSUSE's wine-devel package does not provide any > > archive files in /usr/lib64/wine/x86_64-unix, whereas wine-devel-32bit > does > > provide archive files under /usr/lib/wine/i386-unix (symlinked with the > > same directory in /usr/lib64). > > It is quite likely a bug on openSUSE's side. They probably didn't even > test > winegcc with the wine-devel packages, as it is a pretty rare case that > someone > needs it. > > I think your best choice would be to build wine from source and install it > to > a custom prefix in your home directory. Hopefully the wine-devel packages > pull > in the right headers etc to make it easy to do. > > e.g. in pseudo code: > > ./configure --enable-win64 --prefix=~/mywine > make && make install # no need for sudo. add -j X for faster build > export PATH=~/mywine/bin:$PATH > > Now you should run winegcc from ~/mywine/bin/winegcc, and it has the 64 > bit .a > files in ~/mywine/lib/wine/x86_64-unix. > > Any .dll.so generated that way should run with your system wide wine > installation, so you should be able to copy it to other machines etc. If > in > doubt check out the oldest Wine version you want your binaries to run on. > > >

Oct. 16, 2024

Re: Trouble compiling Winelib DLL for 64-bit on OpenSUSE

by Stefan D�singer

Hello Alexander, Am Dienstag, 15. Oktober 2024, 15:18:57 GMT+3 schrieb aleithner(a)level101.at: > I have previously asked about the problem I'm describing below on openSUSE's > forums [1], StackOverflow [2] and Wine's forums [3], where dimesio told me > that I could try to ask here. If this is the wrong place to ask, I > apologise. The mailing ist is the right place to ask :-) I'll try to answer some of your questions below, but I am not much of a winelib expert and sadly winelib is getting relatively little love. In my quick test building a 32 and 64 bit .dll.so worked, but I would not be surprised if there are bugs. Wine itself has transitioned to a more formal (fake-)syscall and unix call interface to switch between the Windows and the Linux side. I think there are no DLLs left in Wine any more that have the old hybrid PE and ELF linkage. > winegcc -m32 -L/usr/lib64/wine/i386-unix -shared -o myproject.dll > myproject_main.c myproject.spec Does the 32 bit DLL link without the -L path? You shouldn't need it, winegcc and winebuild should know their installation path. > As I've discovered, openSUSE's wine-devel package does not provide any > archive files in /usr/lib64/wine/x86_64-unix, whereas wine-devel-32bit does > provide archive files under /usr/lib/wine/i386-unix (symlinked with the > same directory in /usr/lib64). It is quite likely a bug on openSUSE's side. They probably didn't even test winegcc with the wine-devel packages, as it is a pretty rare case that someone needs it. I think your best choice would be to build wine from source and install it to a custom prefix in your home directory. Hopefully the wine-devel packages pull in the right headers etc to make it easy to do. e.g. in pseudo code: ./configure --enable-win64 --prefix=~/mywine make && make install # no need for sudo. add -j X for faster build export PATH=~/mywine/bin:$PATH Now you should run winegcc from ~/mywine/bin/winegcc, and it has the 64 bit .a files in ~/mywine/lib/wine/x86_64-unix. Any .dll.so generated that way should run with your system wide wine installation, so you should be able to copy it to other machines etc. If in doubt check out the oldest Wine version you want your binaries to run on.

Oct. 15, 2024

Re: Discussing paths forward for OpenGL mappings on Wow64

by Stefan Dösinger

> Am 14.10.2024 um 22:38 schrieb Derek Lesho <dlesho(a)codeweavers.com>: > >> The dosemu2 dev pointed out a way to achieve something similar to macos' mach_vm_remap on Linux. I have to find my email in the archive and will forward his suggestion. It does sound somewhat hacky to me, I am not sure if we want to use it. >> > Oh interesting, yeah that be cool to see. Regardless, even if we have that path, we would probably want to also have a proper long term solution, like how we have the host external memory backup hack in winevulkan. I found the old emails (or part of them). I doubt the idea is workable, but here we go: The trick is essentially to replace the high address mapping behind the external library's back. In pseudo code void *wine_glMapBuffer(int bo) { struct buffer *buf = some_lookup(bo) int fd = shmmem_alloc(buf->size); void *high_addr = host_glMapBuffer(buf->host_bo); void *low_addr = wine_find_some_4g_space(size); mmap(high_addr, buf->size, PROT_RW, MAP_FIXED, fd, 0); mmap(low_addr, buf->size, PROT_RW, MAP_FIXED, fd, 0); return low_addr; } This has a non-zero chance of working if the GL library just reads/writes to its own allocation via the CPU. Replacing the mapping will probably destroy any magic properties (like memory mapped video memory) the driver put in place. And it will break if the pointer returned isn't page aligned and maybe comes from a larger allocation. and and and. So I doubt it is going to fly. In the dosemu2 code there's some sweet looking code here: https://github.com/dosemu2/dosemu2/blob/92705ab35e136bfef2e0206af7c05518ae2… . It looks like it maps void *source to void *target. I tried to follow it through the rest of the code a bit to see if the callers expect *source to remain valid, but couldn't easily figure out how this is all used. --- >> Fwiw as far as wined3d-gl is concerned, it can play nice with slow bounce buffers too. It should do the right thing if GL_ARB_buffer_storage is not available. d3d isn't as badly affected by the performance penalty, although there are games that profit from persistent maps. > I think Aida mentioned this path was prohibitively slow for WineD3D, not sure which games they were referring to. There are certainly games that are either slow (d3d10/11) or outright broken (d3d8/9) without coherent buffers. d3d8/9 games can break without coherent maps if they pass incorrect map lengths. Coherent maps allow us to ignore the length and let the driver figure out what was actually written. I did come across a reverse side of this though [0]: A game that experienced a big regression on ARM hardware *with* coherent buffers. The background was that x86 and that particular ARM chip had entirely different ideas how slow reading from write-combined buffers is. 0: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8301

Oct. 15, 2024

Trouble compiling Winelib DLL for 64-bit on OpenSUSE

by aleithner＠level101.at

Hi, I have previously asked about the problem I'm describing below on openSUSE's forums [1], StackOverflow [2] and Wine's forums [3], where dimesio told me that I could try to ask here. If this is the wrong place to ask, I apologise. Over the past few weeks, I've been re-implementing a DLL using Winelib to be able to leverage Unix sockets to communicate with a Linux process outside of Wine. For context, I'm on a 64-bit machine running openSUSE Tumbleweed. I've had success compiling the DLL as a 32-bit object using the command line winegcc -m32 -L/usr/lib64/wine/i386-unix -shared -o myproject.dll myproject_main.c myproject.spec This DLL (myproject.dll.so) works as expected, i.e. 32-bit Windows programs running under Wine can load and execute the DLL just fine. (I've found specifying -L/usr/lib64/wine/i386-unix to be necessary since WineGCC didn't pick up Wine's library path by itself.) Now, I've been trying to compile this same project as a 64-bit object using winegcc -L/usr/lib64/wine/x86_64-unix -shared -o myproject64.dll myproject_main.c myproject.spec and I'm facing the following WineGCC output: /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -ladvapi32: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -luser32: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -lwinecrt0: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -lkernel32: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -lntdll: No such file or directory collect2: error: ld returned 1 exit status winegcc: /usr/bin/gcc failed As I've discovered, openSUSE's wine-devel package does not provide any archive files in /usr/lib64/wine/x86_64-unix, whereas wine-devel-32bit does provide archive files under /usr/lib/wine/i386-unix (symlinked with the same directory in /usr/lib64). Interestingly, I've inspected Wine's Fedora packages [4] and haven't found these archive files for 32-bit but only for 64-bit; so, the Fedora packages seem to have the opposite "problem." Now, I've tried to use the archive files provided by openSUSE's 64-bit wine-devel package under /usr/lib64/wine/x86_64-windows, but of course they're PE binaries so LD complains it can't link to my Winelib DLL: /usr/bin/ld: relocatable linking with relocations from format pe-x86-64 (/usr/lib64/wine/x86_64-windows/libwinecrt0.a(debug.o)) to format elf64-x86-64 (tmp66fd686a/myproject64-00000001.spec-00000001.o) is not supported winebuild: /usr/bin/ld failed with status 1 winegcc: /usr/bin/winebuild failed I feel like I should be able to compile this Winelib DLL as both a 32-bit and a 64-bit object respectively, on any supported system. (I haven't found any info on this skimming through the Winelib User's Guide [5].) Is this assumption wrong? If so, what's the correct way of building Winelib DLLs? If not, how can I get a 64-bit version of this DLL? Any advice on what I might be misunderstanding or doing wrong or what might be the cause of this problem would be greatly appreciated. Best regards, Alexander Leithner [1]: https://forums.opensuse.org/t/wines-64-bit-archive-files-are-missing/179038 [2]: https://stackoverflow.com/questions/79058718/whats-the-correct-way-of-build… [3]: https://forum.winehq.org/viewtopic.php?t=39513 [4]: e.g. https://dl.winehq.org/wine-builds/fedora/40/x86_64/wine-staging-9.19-1.1.x8… under /opt/wine-staging/lib64/wine inside the package [5]: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-Guide

Oct. 15, 2024