(Sorry, I accidentally hit send before I was done composing...)
On 9/8/21 6:35 PM, Aaron Puchert wrote:
The list of dependencies that we intend to build using MinGW is no > quite fixed yet, but we expect it to include and be mostly limited>
to the following:
- zlib (currently included via manual source import)
What puts a dependency on this list? Wine will typically also use the graphics stack, typically provided by Mesa. Why is that not included?
Here is my very limited understanding of Wine: the <arch>-windows directory provides DLLs that a Windows application might need. These are regular PE libraries so that Windows applications don't get confused. Internally some of these libraries load libraries from <arch>-unix, but these aren't exposed to the Windows application. So they can be ELF executables, which in turn enables them to link system libraries, including those from the above list. That seems like a pretty clean design, although I don't know which problems it might produce.
Now let's say we have something like libfreetype as PE, hence also most, if not all libraries in <arch>-unix. Then we could use a unified loader, but applications might see all these implementation details. Additionally, you'll likely still need to load ELF libraries at some point, because I don't think you'll want to build your own Mesa, LLVM, and all that comes with it.
Yes, we still need to load actual ELF code. The determining questions are something like:
(1) Is it easy to compile in PE format?
(2) Does it need to interact with the host system, say, in terms of configuration files?
(3) Does it need to call down into the OS at some level, in ways that Windows can't replicate?
So anything that interacts with devices is right out (Mesa, audio libraries, libusb, udev, libSDL as used for gamepads, v4l2, gphoto2, cups, sane ...).
fontconfig can be built PE (and I've seen applications in the wild use it) but we need it to detect *host* fonts.
GStreamer can be built PE, but we want to use host codecs where possible (also, Wine will probably end up shipping statically compiled libraries if only as a fallback, and I think we don't want to distribute patent-encumbered codecs.)