On Thursday, October 17th, 2024 at 20:23, Alexander Leithner aleithner@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/