Sorry for double-posting, my mail client helpfully removed everything
from CC for me :-(
On 9/2/21 12:34 PM, Daniel P. Berrangé wrote:
On Thu, Sep 02, 2021 at 12:11:43PM -0500, Zebediah Figura (she/her)
wrote:
> On 9/2/21 12:08 PM, Florian Weimer wrote:
>> * Zebediah Figura:
>>
>>> (2) If we use dynamic libraries, should dependencies be included in
>>> the main wine package, or packaged separately?
>>
>> Aren't many of them already packages separately? For example
>> mingw32-libpng and mingw32-gnutls?
>
> Thanks, I wasn't aware of these. I had tried to search for Fedora mingw
> packages, but didn't realize that looking up "mingw" on
rpmfind.net
wasn't
> enough :-/
>
> Note that this ties into (3) though. It would presumably be enough for
> static libraries, but we need specially named shared libraries, and we can't
> "just" use these packages since as far as I'm aware there's no
standardized
> way to find them.
Why does wine need to use special names ?
Some Windows applications ship and link to their own versions of these
libraries. They might have a wrong major version, or be out of date in
some critical way. Because of the way the Windows loader works (and
therefore, necessarily, the Wine loader), if a DLL links to zlib1.dll
and a DLL named zlib1.dll has been already loaded in memory, that DLL
will be the one loaded. Then you can get an ugly situation like:
* application foo.exe links to zlib1.dll
* application copy of zlib1.dll is loaded
* application loads Wine's builtin opcservices.dll
* opcservices.dll links to zlib1.dll
* application copy of zlib1.dll is already loaded, so we don't load the
system copy
* opcservices.dll tries to use some newer feature of zlib1.dll and fails.
Or a reverse:
* application links to opcservices.dll
* Wine loads the builtin copy of zlib1.dll
* application loads zlib1.dll, expecting its own
* application tries to use some custom-patched feature of zlib and
breaks when it's not present.
Admittedly zlib is a bad example when it comes to breaking
compatibility, but it was the first DLL name that came to mind
So for shared libraries, we need Wine-specific names to make sure that
we don't conflict with application-shipped libraries. And this applies
recursively to dependencies.