https://bugs.winehq.org/show_bug.cgi?id=49920
Bug ID: 49920 Summary: wine: could not load ntdll.so, and more Product: Wine Version: 5.18 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: loader Assignee: wine-bugs@winehq.org Reporter: ferion11@hotmail.com Distribution: ---
When using custom path and environment, through environment variables, wine-vanilla v5.17-v5.18 fails to load with the error:
wine: could not load ntdll.so: /my/path/lib/wine/fakedlls/ntdll.so: cannot open shared object file: No such file or directory
And if I create a symbolic link to the wrong place in ntdll.so, it tries to load the wine executable in another place that isn't even in the environment variables:
/my/path/usr/lib32/wine: error while loading shared libraries: /my/path/usr/lib32/wine: cannot open shared object file: No such file or directory
For the info: Wine is installed in /my/path/ (bin, lib, share...), and the dependency libraries in /my/path/usr/ (bin, lib, lib32)
The v5.16 works, then I made the bisect:
4826900a30a431faa8bcc9e3f0007f794d8d15bb is the first bad commit commit 4826900a30a431faa8bcc9e3f0007f794d8d15bb Author: Alexandre Julliard julliard@winehq.org Date: Tue Sep 8 09:55:38 2020 +0200
loader: No longer depend on libwine.
Signed-off-by: Alexandre Julliard julliard@winehq.org
loader/Makefile.in | 4 +- loader/main.c | 159 +---------------------------------------------------- 2 files changed, 5 insertions(+), 158 deletions(-)
https://bugs.winehq.org/show_bug.cgi?id=49920
Daniel Ribeiro da Silva ferion11@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |4826900a30a431faa8bcc9e3f00 | |07f794d8d15bb CC| |ferion11@hotmail.com, | |julliard@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=49920
--- Comment #1 from Daniel Ribeiro da Silva ferion11@hotmail.com --- The variables in use are: PATH="/my/path/bin:/my/path/usr/bin:${PATH}" WINEVERPATH="/my/path" WINESERVER="/my/path/bin/wineserver" WINELOADER="/my/path/bin/wine" WINEPATH="/my/path/bin:/my/path/lib/wine:${WINEPATH}" WINEDLLPATH="/my/path/lib/wine/fakedlls:${WINEDLLPATH}"
https://bugs.winehq.org/show_bug.cgi?id=49920
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=49920
--- Comment #2 from Alexandre Julliard julliard@winehq.org --- WINEDLLPATH should point to lib/wine, not lib/wine/fakedlls.
https://bugs.winehq.org/show_bug.cgi?id=49920
--- Comment #3 from Daniel Ribeiro da Silva ferion11@hotmail.com --- (In reply to Alexandre Julliard from comment #2)
WINEDLLPATH should point to lib/wine, not lib/wine/fakedlls.
ok! It worked this way for a long time, but changed it now to: PATH="/my/path/bin:/my/path/usr/bin:${PATH}" WINEVERPATH="/my/path" WINESERVER="/my/path/bin/wineserver" WINELOADER="/my/path/bin/wine" WINEPATH="/my/path/bin:/my/path/lib/wine:${WINEPATH}" WINEDLLPATH="/my/path/lib/wine:${WINEDLLPATH}"
and still got the error: /my/path/usr/lib32/wine: error while loading shared libraries: /my/path/usr/lib32/wine: cannot open shared object file: No such file or directory
but my wine executable is on /my/path/bin/wine
https://bugs.winehq.org/show_bug.cgi?id=49920
--- Comment #4 from Daniel Ribeiro da Silva ferion11@hotmail.com --- (In reply to Alexandre Julliard from comment #2)
WINEDLLPATH should point to lib/wine, not lib/wine/fakedlls.
By the way, this change breaks the working of all my wine compilations, before the regression commit.
https://bugs.winehq.org/show_bug.cgi?id=49920
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- That's not really a change, WINEDLLPATH should always have pointed to the dlls. You maybe didn't notice the wrong path before because it wasn't used when libwine was loaded first.
For 32-bit you need to either pass the correct --libdir to configure, or add the 32-bit lib dir to WINEDLLPATH.
https://bugs.winehq.org/show_bug.cgi?id=49920
--- Comment #6 from Daniel Ribeiro da Silva ferion11@hotmail.com --- (In reply to Alexandre Julliard from comment #5)
That's not really a change, WINEDLLPATH should always have pointed to the dlls. You maybe didn't notice the wrong path before because it wasn't used when libwine was loaded first.
For 32-bit you need to either pass the correct --libdir to configure, or add the 32-bit lib dir to WINEDLLPATH.
Well, I clearly see the intention for this to work this way, but I don't see it working that way in practice. Perhaps, you could point me out how to change all variables at run time (without fixed compilation paths, because "/my/path" is random), and that works for cases before commit and after it (in both 32-bit and 64-bit WoW64 versions).
After changing the variable of a working version of wine v5.11, it stopped working with a similar error: /my/path/usr/lib32/wine: error while loading shared libraries: /my/path/usr/lib32/wine: cannot open shared object file: No such file or directory
https://bugs.winehq.org/show_bug.cgi?id=49920
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- It's hard to tell without seeing all the details of your setup, but a valid WINEDLLPATH should work the same way before and after the change. Note that you can put multiple directories in WINEDLLPATH, for instance both 32-bit and 64-bit lib dirs.
https://bugs.winehq.org/show_bug.cgi?id=49920
--- Comment #8 from Daniel Ribeiro da Silva ferion11@hotmail.com --- (In reply to Alexandre Julliard from comment #7)
It's hard to tell without seeing all the details of your setup, but a valid WINEDLLPATH should work the same way before and after the change. Note that you can put multiple directories in WINEDLLPATH, for instance both 32-bit and 64-bit lib dirs.
Well, even just adding lib/wine to WINEDLLPATH in versions already working, stops it from working.
My setup is unified in an AppImage that includes all 32-bit dependencies (for users of no-multilib distributions):
* All working: https://github.com/ferion11/Wine_Appimage
* Still in stability tests: https://github.com/ferion11/Wine_Appimage_dev
Made to be used to install LogosBible using the script: https://github.com/ferion11/LogosLinuxInstaller
Of the versions with v5.18, the only one that still works is the tkg, since Tk-Glitch reversed the changes of this commit, as we can see here: https://raw.githubusercontent.com/Tk-Glitch/wine-tkg/master/loader/main.c
* and I'm making preparations for the WoW64 version too
https://bugs.winehq.org/show_bug.cgi?id=49920
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED
--- Comment #9 from Alexandre Julliard julliard@winehq.org --- Looking at your code, I suspect the bug is that the path of the custom ld-linux.so.2 loader ends up as the bin directory, and so we try to exec wine from there (the /usr/lib32/wine path). Normally that would fail and we'd fallback to WINELOADER (cf. loader_exec() in dlls/ntdll/unix/loader.c), but your exec replacement routine in libhookexecv.c is not going to fail for nonexistent paths, it will exec and then die when loading.
Detecting all possible failures would be tricky, but adding a simple "if (stat(path,&st)) return -1;" at the top of the execv hook may be good enough.
https://bugs.winehq.org/show_bug.cgi?id=49920
m0rvj johnpgoodman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johnpgoodman@gmail.com
--- Comment #10 from m0rvj johnpgoodman@gmail.com --- I don't think this affects Logos Bible Software any more... is it resolved? I think it could be closed.
-
WineHQ Bugzilla