Request for discussion: Using PE libraries for Wine dependencies

[Zebediah Figura]

On 4/13/20 12:43 PM, Erich E. Hoover wrote:
> On Mon, Apr 13, 2020 at 10:08 AM Gabriel Ivăncescu
> <gabrielopcode at gmail.com> wrote:
>> ...
>> FWIW, if this approach is chosen, I think they should first go (or be
>> read in) somewhere in wine's directory, like other libs (or how Proton
>> bundles its libs in <wine_dir>/lib{,64} for example) and the system-wide
>> paths after that if those aren't found (or maybe not at all, because
>> most distros don't even ship with mingw libraries... and I hate being
>> reliant on this fact).
>>
>> This is so you can use specific wine versions with specific libraries if
>> you wish to do so, instead of a single system-wide choice for all
>> versions. It also makes them potentially neatly stored in one place.
>>
>> This is more important since you won't be able to use LD_LIBRARY_PATH or
>> LD_PRELOAD either to "hack" the load order for debugging or any other
>> reason.
>>
>> Also, you'll be able to use Wine with older distros or otherwise more
>> obscure ones that don't package them. Just drop it and run from its
>> directory.
> 
> Why don't we modify LoadLibrary and GetProcAddress to function as
> dlopen/dlsym when passed an ELF library?  This should allow us to
> rework all our libraries in PE format without having to distribute a
> mess of dependencies, and still allow us to respect LD_LIBRARY_PATH
> and LD_PRELOAD settings.

I guess that broadly this negates most of the advantages Esme enumerated
in the first place. It makes converting our libraries to PE easier, but—

* we still have to (presumably manually) swap out of "PE mode" when
making those calls (which, as I understand, will involve such things as
saving thread context and swapping registers like aarch64's x18).
Granted, we'd have to do this anyway for some libraries, but not having
that overhead may also be helpful.

* we're still requiring both libfaudio.so and FAudio.dll (that Mono needs);

* I think we'd also run into problems with headers, since the ABI is
diffferent. Granted, that might be easy to fix with compiler options
(maybe just by not using -mabi=ms?)

> 
> Best,
> Erich
>