On 8/31/21 2:30 PM, Alexandre Julliard wrote:
"Zebediah Figura (she/her)" zfigura@codeweavers.com writes:
On 8/31/21 1:25 PM, Alexandre Julliard wrote:
"Zebediah Figura (she/her)" zfigura@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/devel@lists.fedoraproject.org/...
[2] https://lists.debian.org/debian-devel/2021/09/msg00074.html
[3] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/A...
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606825