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) wrote:
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.
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
need.
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
it's present...
_______________________________________________
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
