On 9/8/21 8:50 AM, Michael Matz wrote:
Hello,
On Tue, 7 Sep 2021, Zebediah Figura wrote:
[A library like libfreetype] can be ahead of Wine's system libraries, behind them, or even built with custom patches. Accordingly we really don't want to load "our" freetype in place of "their" freetype, or "theirs" in place of "ours".
(1) Should we build via source import, or link statically, or dynamically?
Anything that is static can not be overridden. But overriding is at the heart of your operation AIUI.
Sorry, I'm not sure I understand. Overriding what exactly?
We don't want to override their libfreetype with ours, or vice versa. We want to give the application the libfreetype it expects, and we want to load the libfreetype we expect. There are many reasons things can break otherwise, but the most realistic is that one of them is older than the other, and is missing some API that either the application or Wine needs.
Well, if you're fearing that, then you should also fear symbol clashes, right? I.e. you not only need to rename the lib basename, but also all exported symbols from your version. (After all, programs could also crawl the export lists). At that point it all becomes cumbersome.
How do deal with that problem currently? Why would that change with the file format of your helper libs? Why should the libfreetype that wine is using for internal purposes be loaded visibly into the process image at all? After all the whole purpose of an emulator is to, well, emulate the target as faithfully as possible, and one of those things would be to provide the target process with only the list of loaded DLLs it would also see on a normal Windows system. I.e. one without freetype or any other libs that you mentioned. The code and data of those libs can of course be loaded if you need them in-target-process, but all the meta data of it should not be readily linked into the normal data structures available to the target process.
Like any problem of emulation, it's a matter of trying to figure out what's "good enough". And the root of the problem here, what we're concerned about, is that the amount of work required to make dynamic libraries "good enough"—by our estimation—is a lot more than it is for static libraries. Currently host libraries are loaded in ELF format, and they're stored somewhere in wine internals. win32 code can see them, if they knew how to look for them, but of course they don't. The idea with PE libraries is that, since we of course already have a PE loader, we just use it for the code we can. There's some solutions that have been proposed internally that would allow us to use system dynamic libraries unmodified. They require doing some hacks to the PE loader. The hacks get worse if we try to remove system libraries from the "known" win32 data structures and put them in our own private ones. It's not clear that these hacks would be acceptable for Wine, and it's not clear that programs wouldn't break anyway for one reason or another. So while we *might* be able to use system libraries unmodified, I didn't really want to present the situation to distributions as if we were sure. But I'm sure that I can at least take this as a sign that openSUSE would like us to use its dynamic libraries if at all possible. It's certainly not alone in that :-)