[Bug 50710] New: relative paths in WINEDLLPATH (as created from $0) no longer work in wine-5.11+
WineHQ Bugzilla
wine-bugs at winehq.org
Mon Feb 22 08:04:35 CST 2021
https://bugs.winehq.org/show_bug.cgi?id=50710
Bug ID: 50710
Summary: relative paths in WINEDLLPATH (as created from $0) no
longer work in wine-5.11+
Product: Wine
Version: 6.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: loader
Assignee: wine-bugs at winehq.org
Reporter: PuetzKevinA at JohnDeere.com
Distribution: ---
Winegcc's app_loader_template deriveds $appdir from $0,
and then adds this directory into WINEDLLPATH:
https://source.winehq.org/git/wine.git/blob/wine-6.0:/tools/winegcc/winegcc.c
appdir=`dirname \"$0\"`
WINEDLLPATH=\"$appdir:$WINEDLLPATH\"
Presumably the intent here is to match LOAD_LIBRARY_SEARCH_APPLICATION_DIR;
windows also searches for dlls immediately beside the main executable.
However, it is not unusual in interactive use for $0 to be a relative path,
e.g. if an executable is invoked as ./hello.exe, and dirname preserves this.
This results in WINEDLLPATH containing relative-path entries; this seems
a bit inadvisable, but it worked through wine-5.10. Since then it does not.
0024:err:module:import_dll Loading library test_shared.dll (which is needed
by L"Z:\\home\\test\\\bin\\test_executable_shared.exe") failed (error
c000003b).
Bisecting first pointed at df5e4764870e8ad1d8b206cb3475a073bc034e48, but
this is just https://bugs.winehq.org/show_bug.cgi?id=49545; after the unix
cwd is lost, a relative-path entry no longer resolves to the right place.
cherry-picking that fix from cdaa72c728df3c80499c8a4f59e731f353347db0
restores functionality, but then it breaks again (for the reason that
is actually breaking it in 6.0) at 9ec262ebcc7f14d7373841d4ca082b855ed8090f
https://source.winehq.org/git/wine.git/blobdiff/a2e77268f2007f2819c2e3e8bd736a056f309a4c..9ec262ebcc7f14d7373841d4ca082b855ed8090f:/dlls/ntdll/unix/loader.c
Previously ntdll/unix/loader.c:open_builtin_file used unix_to_nt_file_name,
which looks like it would have just flipped the slashes to translate a
a relative unix path to a relative NT path, which would then use NT's cwd
(hence susceptibility to https://bugs.winehq.org/show_bug.cgi?id=49545),
But now it uses open_unix_file, which calls SERVER_START_REQ( create_file ),
which just refuses relative paths STATUS_OBJECT_PATH_SYNTAX_BAD
https://source.winehq.org/git/wine.git/blob/wine-6.0:/server/file.c#l214
This is an error other than STATUS_OBJECT_{PATH,NAME}_NOT_FOUND, so it stops
https://source.winehq.org/git/wine.git/blob/wine-6.0:/dlls/ntdll/unix/loader.c#l1241
I'm not sure what the best fix here really is... relative paths in WINEDLLPATH
seem like a pretty bad idea (since the cwd may change as the process runs,
environment variables leak down into child processe, etc), but the launcher
script's been like this for a long time.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
More information about the wine-bugs
mailing list