Hello, On Thu, 9 Sep 2021, Zebediah Figura wrote:
But why? You also have an ELF loader that you don't even need to maintain yourself (in ld.so), why would you want to use the target object loader (PE) for the host binaries (the wine code) when you can load host files perfectly fine already?
Right, I omitted the explanation for the sake of simplicity (not that it helped very much, my mail still ended up very long). Let me try to explain in detail; please feel free to ask for further clarification if necessary.
The basic reason is that Wine is essentially trying to split itself into "PE" and "Unix" parts. The idea is that all of the "user" code is built in PE format, and only calls into unix code by making a sort of fake "syscall". The "kernel" code is built in ELF format (or whatever the host system loads).
Okay, define "user" code then. From your initial list of libs:
* libvkd3d * libFAudio * libgnutls * zlib (currently included via manual source import) * libmpg123 * libgsm * libpng * libjpeg-turbo * libtiff * libfreetype * liblcms2 * jxrlib
Why is, for instance, libpng or libfreetype such user code? No Windows program will make use of facilities of these libraries (and if they do, they have an explicit dependency on a self-provided freetype.dll). So it seems your definition of user code extends to something beyond just the emulated windows program. I could imagine one thing: you have (of course) code that is part of some existing PE libs which really are intentionally loaded visibly into the target process (like any of the well known MS DLLs), but the implemention of functions in them actually makes use of facilities of the above libraries (like decoding PNGs). Is that it? If so, your argument about the unix<->PE border makes sense, and I see how one would like to build the above helper libs such that they can be included from your existing PE libs. (Either by statically including the code within the PE libs, or by making the above libs be themself PE DLLs) But I don't see how much a distro can help here. Especially the requirement about providing libfoo as PE DLL, but not named libfoo, but rather libfoo-for-wine-internals, to not overtly pollute the targets namespace, makes the whole thing fairly specific and un-distro-like. An extension to the PE loader of wine to support an internal namespace would help with that: a distro could provide a libfoo PE DLL package without strange renaming. (And such internal namespace would also help with some of the raison d'être for the whole stunt: not exposing the libs metadata to the process would make anti-cheaters not tripp over non matching memory/disk). Such PE DLL package could then theoretically be used in other packages that want to build PE executables that directly make use of e.g. libpng.dll . But it's still a stretch: you understandably want to use libraries that exist on the system for 3rdparty stuff you depend on. But the very act of building it as PE files already makes it non-system-provided. Nothing on the system except wine would use these files, so the usual arguments of why system libs are better (heavy testing, quicker updates for bugs) become weak quickly. If the source code between libfoo.rpm/deb and libfoo-dll.rpm/deb would be shared (i.e. they fall out of the same package source container) then at least you would benefit from quick bug fixes, but I think it's questionable if packagers are happy to have to provide for a cross compiled libpng package when they actually need to care for the system libs. Hmm, rock and hard place? :-) I don't have a good suggestion. What would be your preference or idea? (Well, I do have a crazy idea: automatically wrap an ELF file into an PE file and generate the glue automatically during wine build or even on the fly during load. You then would "properly" load the PE file into the target process, and that it happens to contain a large blob of bytes that happens to look like an ELF file is just a random little fun fact. The ABI switching glue isn't too terrible. But of course that still leaves the 32bit vs. 64bit problem: the system ELF libs will most often be 64bit, but you could depend on and wrap the -32bit variants as well if they exist) Ciao, Michael.