On 9/22/25 12:43, Elizabeth Figura wrote:
On Monday, 22 September 2025 13:31:49 CDT Paul Gofman wrote:
On 9/22/25 12:14, Elizabeth Figura wrote:
On the other hand, I am reminded of an unrelated bug, involving a program (I don't have the name unfortunately) which copies ws2_32.dll to a temp file with a randomly generated name and attempts to load the copy. This fails on Wine because ws2_32 has a unixlib, and we derive the name of the unixlib from the path of the DLL. In order to fix this bug we would probably need to embed the name of the unixlib in the DLL itself rather than relying on its path. If we did that the DLLs for winepulse and winealsa would no longer be identical.
That doesn't look quite related to the discussed issue? This part is about how we find Unix library.
The point is that if we were to do this, winepulse and winealsa would no longer have the exact same contents, which would sidestep this problem.
I see now why are those are the same, the PE part may be identical indeed. But it is only a particular case, the bug will stay in general, there will be other cases when things are broken due to that (while probably not reproducible across majority of apps under Wine).
I didn't check exactly this case lately but doesn't Wine search for Unix libraries in the configured or determined on start Wine paths now? I'd guess it might just work?
The problem isn't the path, it's the base name. ws2_32.dll gets renamed to "tmp1234.dll" or something, and we look for (and fail to find) "tmp1234.so".
Ah, it is renamed...