On 9/2/21 1:04 PM, Daniel P. Berrangé wrote:
On Thu, Sep 02, 2021 at 12:46:09PM -0500, Zebediah Figura (she/her)
> 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
>>> 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
>>> "just" use these packages since as far as I'm aware there's
>>> 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.
Is it possible to modify existing DLLs to update their name ? I presume
it is more than just renaming the file itself - some internal data field
containing the reference name, similar to ELF's SONAME field ?
I'm thinking if you can just "edit" the existing DLLs to set the new
name, then it is possible to avoid building & packaging it all twice
We can rename DLLs at install time, but it's trickier than that—we need
to also rename their imports. Patching import tables is not trivial.
That said, I think I may have been wrong: there *may* be a workable
solution that lets us use system DLLs without renaming. I'm not sure
that we won't hit any internal snags, but it doesn't seem out of the
question just yet.
It's worth pointing out that we will almost certainly need a fallback
solution, if we do end up using shared libraries and
*-w64-mingw32-pkg-config. This is mainly because Fedora, as far as I can
tell, is unusual in providing mingw libraries (Debian ships a scant few;
Arch ships none and in fact only recently even started shipping the
cross-compiler.) And even Fedora doesn't provide all of the libraries we
I'm happy to work with Fedora and with other distributions to help get
support across the board for mingw libraries and pkg-config, but it's
going to be a hard sell to the Wine maintainers to rely on a feature
that isn't widely supported. Still, we might be able to use it where