On 4/12/20 8:56 PM, Esme (they/them) wrote:
I guess it's not obvious to me there's a difference between "builtin" and "distro" (though we'd presumably not go putting the Wine builtin flag in mingw libraries). But yeah, I guess we'd want to vary load order depending on whether the library is a dependency of a PE builtin or not, in some way.
I was thinking about the possibility of a distro shipping a dll that's also a Wine builtin. But, we could probably resolve that case by saying "builtin" searches for wine builtins before distro libraries.
I guess we'd want the load order to be something like:
- If explicitly set in registry or environment, use that.
- If Wine builtin, use preattach.
- If dependency of Wine builtin that exists in distro search path,
builtin,native.
- If dependency of a dll in distro search path (but not a Wine
builtin), builtin,native.
- Otherwise, native,builtin or maybe even native only (should Wine
ever use a distro library to resolve dependencies of the application?).
This last one is a good question. Would we necessarily expect an application-provided PE library to differ from a distro mingw library? (Maybe because of a lack of backwards compatibility?) To a degree it feels much like preferring builtin d3dx9 when the application provides its own.
It also kind of ties into bugs like 14980, 20777, 25373, 43472, 45551, 47053, 47120, 48275 where preferring builtin DLLs break applications. I recall that always preferring native breaks other applications, though I don't know any concrete examples... but since I have yet to hear a solution to this problem, I have to wonder if it would be better in general to use native,builtin for all direct dependencies of native DLLs.
(Presumably we'd want native,builtin rather than native only in any case. The number of cases where applications import DLLs but don't ship them is pretty small, in my experience? Though that doesn't include dynamically loading...)