On Tue, 7 Sep 2021, Zebediah Figura wrote:
[A library like libfreetype] can be ahead of
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
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
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.