[Bug 50710] New: relative paths in WINEDLLPATH (as created from $0) no longer work in wine-5.11+

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
      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.

[Bug 50710] relative paths in WINEDLLPATH (as created from $0) no longer work in wine-5.11+

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50710

--- Comment #1 from Kevin Puetz  ---
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

[Bug 50710] relative paths in WINEDLLPATH (as created from $0) no longer work in wine-5.11+

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50710

Vitaly Lipatov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]