https://bugs.winehq.org/show_bug.cgi?id=50710
--- Comment #1 from Kevin Puetz PuetzKevinA@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