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