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@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.
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?"