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.