[Bug 51541] nvcuda.dll unable to load within Steam Runtime pressure-vessel

WineHQ Bugzilla wine-bugs at winehq.org
Wed Aug 18 16:22:47 CDT 2021


https://bugs.winehq.org/show_bug.cgi?id=51541

--- Comment #10 from Liam Middlebrook <loothelion at nvidia.com> ---
> I would assume that in the case of multiple SONAME's of the same lib, whatever highest version will be used.

I'm not sure that is what happens, but either way that wouldn't work. The
versions are not guaranteed to be ABI-compatible with one another.

Take for example if Bob wrote a patch to wine that adds some new DLL that makes
use of libcurl. Bob uses Debian Etch so he wrote the patch against
libcurl.so.3. Then Alice comes along and downloads Bob's patch to build Wine
for herself with the patch. Alice uses Archlinux so she has libcurl.so.4. While
Bob's patch may key off of a particular function being available, it doesn't
protect against future ABI changes in other functions. Alice is able to build
Wine successfully, the configure step picking up libcurl.so.4. Then at runtime
the dlopen call to libcurl.so.4 succeeds, and a subsequent dlsym call for one
of the functions succeeds, but the function signature has changed, so then Wine
ends up calling that function in a way that results in issues.

This solution may not always be applicable, but it seems like in some cases
Alice (or someone else) could write patches that have different paths depending
on if libcurl.so.3 or libcurl.so.4 are available on the system. This could
either be done via an ifdef, or at runtime depending on how portable Wine
builds are expected to be.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list