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
--
|: