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.
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
