8 Sep
2021
8 Sep
'21
23:35
Am 07.09.21 um 01:36 schrieb Zebediah Figura: > For a long time Wine has built all of its Win32 libraries (DLLs and > EXEs) as ELF binaries. Wait, so I have two directories with libraries: * /usr/lib64/wine/x86_64-unix/ containing according to "file": "ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked". * /usr/lib64/wine/x86_64-windows/ containing according to "file": "PE32+ executable (DLL) (console) x86-64, for MS Windows" plus some non-libraries. So I assume we're only talking about the-unix directory, right? > 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: > > * libvkd3d > * libFAudio > * libgnutls > * zlib (currently included via manual source import) > * libmpg123 > * libgsm > * libpng > * libjpeg-turbo > * libtiff > * libfreetype > * liblcms2 > * jxrlib 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 -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 -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 -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. Best regards, Aaron