[Bug 50710] New: relative paths in WINEDLLPATH (as created from $0) no longer work in wine-5.11+
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(a)winehq.org Reporter: PuetzKevinA(a)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.... 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/a2e77268f2007f2819c2e3e8bd73... 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... 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.
https://bugs.winehq.org/show_bug.cgi?id=50710 --- Comment #1 from Kevin Puetz <PuetzKevinA(a)JohnDeere.com> --- A couple of ideas: 1. the app_loader_template could use realpath, to avoid putting relative paths in WINEDLLPATH in the first place (wouldn't fix any existing launcher scripts though) 2. set_dll_path() could use realpath to resolve entries before storing them into dll_paths[]. This way they'd at least be stable during the whole run, though they'd still leak into child processes. 3. loader could get the app path from ProcessParameters->ImagePathName (as LOAD_LIBRARY_SEARCH_APPLICATION_DIR already does for native), and the loader scripts could just quit fiddling with WINEDLLPATH. Or if there's a good reason wine doesn't just do this always, we could do like rpaths do, and use something special like WINEDLLPATH=\$ORIGIN the opt-in that inherits, without unrelated child processes inheriting the actual path. This again wouldn't fix any existing launcher scripts, though) Looking at it as a regression suggests doing both 1 and 2 - 1 avoids putting the loader in this awkward situation, and 2 restores the previous behavior for any old foo.exe launcher scripts. But 3 feels like a more "correct" behavior, at least if I've understood what this addition to WINEDLLPATH was for in the first place -- 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.
https://bugs.winehq.org/show_bug.cgi?id=50710 Vitaly Lipatov <lav(a)etersoft.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lav(a)etersoft.ru -- 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.
participants (1)
-
WineHQ Bugzilla