On 4/13/20 12:43 PM, Erich E. Hoover wrote:
On Mon, Apr 13, 2020 at 10:08 AM Gabriel Ivăncescu gabrielopcode@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