[RFC PATCH 0/5] XAudio PE conversion.

[Dean Greer]

For a fixed location a better path would be /opt/wine/ext as /opt/wine is
already used for both wine-mono (/opt/wine/mono) and wine-gecko
(/opt/wine/gecko)

On Thu, Sep 2, 2021 at 3:20 PM Zebediah Figura (she/her) <
zfigura at codeweavers.com> wrote:

> On 8/31/21 10:06 PM, Zebediah Figura (she/her) wrote:
> > On 8/31/21 2:30 PM, Alexandre Julliard wrote:
> >> "Zebediah Figura (she/her)" <zfigura at codeweavers.com> writes:
> >>
> >>> On 8/31/21 1:25 PM, Alexandre Julliard wrote:
> >>>> "Zebediah Figura (she/her)" <zfigura at codeweavers.com> writes:
> >>>>
> >>>>> (3) Most importantly, I would like to coöperate with distributions.
> As
> >>>>> I understand, they already don't like the way we distribute wine-mono
> >>>>> and wine-gecko, and I don't think we should annoy them any further by
> >>>>> going behind their back and distributing more pre-built libraries.
> >>>>>
> >>>>> I know people here think that they won't want to distribute PE
> >>>>> libraries, but I'm inclined to think that at least some distributions
> >>>>> won't be happy with our proposed solution either. See [1] [2] [3] [4]
> >>>>> for popular distributions trying to discourage source imports and
> >>>>> static libraries. I get that we're a special case, and maybe
> >>>>> distributions will think so too, but I really want to again argue
> that
> >>>>> we shouldn't be making that decision for them.
> >>>> Have you tried asking them?
> >>>
> >>> I haven't yet. I didn't really want to speak on behalf of the Wine
> >>> project if the consensus was against consulting them, and I didn't
> >>> want to start that conversation without the possibility that its
> >>> fruits would at least be taken into account. But if there are no
> >>> objections I'll start writing some mails.
> >>
> >> I don't see any harm in asking. I'll admit that I'm fairly skeptical, so
> >> it will be up to you to build a convincing case. Getting the buy-in of
> >> the major distros is obviously a required step.
> >
> > Well, to be clear, I'm not even necessarily trying to build a case
> > (anymore); I'd just like to not leave them out of the conversation.
> >
> > In particular, I think distributions *may* want to encourage us toward
> > dynamic linking, and they also *may* want to distribute dependencies
> > separately (so that they can, say, distribute our libgnutls in sync with
> > ELF libgnutls in case they need to do a security update). For that
> > matter that doesn't necessarily preclude building everything with
> > submodules, although I personally would like to avoid submodules or
> > anything like them.
> >
> >>
> >>>> Remember that we need the libs to have custom names, to avoid
> conflicts
> >>>> with Windows apps shipping the same libs.
> >>>
> >>> Yep, I've been keeping that in mind. If we want to distribute shared
> >>> libraries I'm inclined to think the best solution there is to copy (or
> >>> symlink, or fake-symlink) them into the prefix with different names.
> >>
> >> This won't work for nested dependencies. For instance the PE libpng is
> >> going to import the PE zlib, so it needs to have been renamed at build
> >> time already.
> >
> > Indeed; that's annoying, but thanks for pointing it out.
> >
>
> Actually, an alternate solution occurred to me:
>
> If we are loading any library that is a dependency of a builtin library,
> always load it from a fixed path like /usr/lib/wine/ext/, and
> essentially treat it as if we had loaded using an absolute path instead
> of a relative path, so as to skip existing DLLs loaded under that name.
>
> Mark that DLL with an internal flag, and don't consider it when
> searching for existing DLLs with that name, to avoid the other side.
>
> I know there are a lot of other things standing in the way of shared
> libraries, and that this would require some nontrivial loader work, but
> does it at least seem plausible? Are there snags I'm not noticing?
>
> At least the first distribution I've talked to (Fedora) already has
> mingw packages for many of our desired PE dependencies, and the initial
> response I got was something along the lines of "why can't you use
> those?" and "is there any way you can avoid having to rename libraries?"
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210902/1dcbbbaa/attachment.htm>