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 Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
