[PATCH 0/1] MR10955: Revert "dxcore: Prefer native."
From: Elizabeth Figura <zfigura@codeweavers.com> This reverts commit 06718e98474937d869c8c9ffb12458db372c5067. As described in the merge request from which this commit originates [1], this is meant to avoid a conflict with an unrelated DLL with the same name. a31ec8da9572672e04ae46792a398da942649875 is a better fix for this problem, and the heuristic works here as the relevant DLL has no version resource. [1] https://gitlab.winehq.org/wine/wine/-/merge_requests/6391#note_80343 --- dlls/dxcore/Makefile.in | 2 -- 1 file changed, 2 deletions(-) diff --git a/dlls/dxcore/Makefile.in b/dlls/dxcore/Makefile.in index 147216555e9..7c7e60f0969 100644 --- a/dlls/dxcore/Makefile.in +++ b/dlls/dxcore/Makefile.in @@ -1,7 +1,5 @@ MODULE = dxcore.dll IMPORTS = wined3d -EXTRADLLFLAGS = -Wb,--prefer-native - SOURCES = \ dxcore.c -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/10955
I thought there were more cases of DLLs getting marked as prefer-native because of applications shipping hooks or unrelated homonyms, but these are the only two I can find. The vast majority seem to simply be DLLs marked as prefer-native due to being stubs, at least when they were introduced. Some of these are no longer particularly stubby (e.g. hid, mf, localspl, taskschd, d3dx). Some of these are relatively useful since the DLL is often bundled (or a redistributable installer is), e.g. d3dx*, quartz, vulkan-1. In other cases it seems quite unlikely that the DLL was ever redistributable (e.g. aclui, joy.cpl). In some cases, even if the DLL was redistributable, it surely could never have worked (e.g. dxva2, dcomp, ksuser, bluetoothapis, fltlib). In two cases I think the "Known DLLs" mechanism prevents application-provided DLLs from being used even on Windows (msctf, shcore). Should we consider getting rid of prefer-native from more DLLs, stubbiness notwithstanding? Should we restrict it to some of the above cases? Is it a matter of "welcome, but whoever does it has to promise to deal with the regressions"? How stubby is stubby? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10955#note_140731
Should we consider getting rid of prefer-native from more DLLs, stubbiness notwithstanding?
Yes, we should always err on the side of using builtin, even for stubby dlls, because as you noted many of them are not redistributable anyway. In many cases I think the flag was added just by copying from some other makefile and not because it actually helped anything. Ideally I'd like to get rid of the prefer-native mechanism completely and rely only on version heuristics. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10955#note_140753
participants (3)
-
Alexandre Julliard (＠julliard) -
Elizabeth Figura
-
Elizabeth Figura (＠zfigura)