[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 <PuetzKevinA at 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.