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. Ciao, Michael.