[RFC PATCH 0/5] XAudio PE conversion.

Thu Sep 16 01:32:07 CDT 2021

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.

I've spent the last couple of weeks asking Fedora [1], Debian [2], 
openSUSE [3], and Arch (private conversation with the maintainer). There 
is, perhaps unfortunately, a unanimous consensus among these that they 
would indeed like to see us use their packages, and to link dynamically 
rather than statically.

Fedora ships about half of the libraries we need already; Debian ships 
only one (if you even count zlib), Arch ships none. But representatives 
from all of these offered to add the missing ones.

Fedora, openSUSE, and Debian all have a MinGW version of pkg-config, 
which can be used to find include and library paths for the relevant 
libraries. Arch doesn't have it, but the AUR does; I think it's a clear 
enough standard to standardize on.

We don't however have a standardized way to find libraries which don't 
have pkg-config support (which I think only ends up being gsm?) We also 
don't have a standardized way to find the runtime path.

(As to the question of why these packages exist in the first place: the 
uses that people mentioned seem to be mostly about cross-compiling 
software for Windows on a Linux host. openSUSE also mentioned that some 
of its packages are used by the WSL loader. In general there appears to 
be some demand for them, but they're also not currently a very high 
priority. For example, Debian has had an open bug [4], with a decent 
amount of discussion, regarding adding mingw support to multiarch 
instead of its current none-arch solution. But being used by Wine would 
certainly change things.)

I brought up the problem of dynamic library conflicts in the above 
discussions; the response was universally along the lines of "we'd 
really prefer it if you could use dynamic libraries", accompanied by 
proposals to work around it on the Wine side. It's not particularly 
surprising that distributions would want this; after all, it means less 
work for them (and more for us), but personally I'm inclined to believe 
it makes sense, and it's worth pursuing if it's at all possible.

So in short, the assumption that distributions don't want to deal with 
our nonsense doesn't seem to hold. For better or for worse.

With that in mind, I believe we will still want some way of building 
that does *not* rely on distribution packages—in case one is building 
from source on a system that doesn't provide any, and doesn't want to 
build them manually.

And given that Fedora and Debian currently package some, but not all, of 
the libraries we need, we should ideally also be able to use what 
distribution packages are available and fall back to static libraries 
for the others.

So I think we do want something like Rémi's solution, but on top of that 
I'd like to propose that we allow for using pre-built dynamic libraries 
where available.

I have attached a set of 3 patches to this mail that should give a very 
rough idea of what this would look like. It comprises an implementation 
of my proposed rudimentary "namespacing" in the loader, and the 
configure bits to look for and use MinGW zlib. The namespacing seems to 
work, after some basic tests. (dbghelp is kind of broken, because it 
doesn't handle multiple identically named libraries, but that needs to 
be fixed anyway.) The runtime dynamic library path is specified via a 
configure variable.

This doesn't include the mentioned fallback mechanism (or apply on top 
of Rémi's patches at all), mostly because it's not clear to me how close 
to the eventual upstream Rémi's patches are.

And yes, it's possible that an application breaks for the simple reason 
that we're using dynamic libraries it doesn't expect. The best I can 
offer is that usually when applications trawl the loader state, they're 
looking for things like ntdll and kernel32, and also that SxS exists and 
so it's not unheard of to see multiple identically named libraries 
anyway. If nothing else I'd like to argue that the risk of breaking, at 
this point, is low enough that it's worth at least trying. If we have a 
fallback mechanism, plus the ability to bisect, it'll be easy enough to 
diagnose failure anyway.

Sorry for being overly verbose in the above, I wanted to accurately 
summarize the discussion and make sure all points had been touched on.

ἔρρωσθε,
Zebediah

[1] 
https://lists.fedoraproject.org/archives/list/[email protected]/thread/SL4IPD2VBMJ2XVGXRYFPDXZIC4YIYPWY/

[2] https://lists.debian.org/debian-devel/2021/09/msg00074.html

[3] 
https://lists.opensuse.org/archives/list/[email protected]/thread/AFJJB3GDL3ZSQNRRAIJYQEHMMPELHUUS/

[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606825
-------------- next part --------------
A non-text attachment was scrubbed...
Name: system-libraries.mbox
Type: application/mbox
Size: 156262 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210916/6af173e4/attachment-0001.mbox>