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