[Bug 49920] New: wine: could not load ntdll.so, and more
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(a)winehq.org Reporter: ferion11(a)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(a)winehq.org> Date: Tue Sep 8 09:55:38 2020 +0200 loader: No longer depend on libwine. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> loader/Makefile.in | 4 +- loader/main.c | 159 +---------------------------------------------------- 2 files changed, 5 insertions(+), 158 deletions(-) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 Daniel Ribeiro da Silva <ferion11(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |4826900a30a431faa8bcc9e3f00 | |07f794d8d15bb CC| |ferion11(a)hotmail.com, | |julliard(a)winehq.org -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #1 from Daniel Ribeiro da Silva <ferion11(a)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}" -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #2 from Alexandre Julliard <julliard(a)winehq.org> --- WINEDLLPATH should point to lib/wine, not lib/wine/fakedlls. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #3 from Daniel Ribeiro da Silva <ferion11(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #4 from Daniel Ribeiro da Silva <ferion11(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #5 from Alexandre Julliard <julliard(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #6 from Daniel Ribeiro da Silva <ferion11(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #7 from Alexandre Julliard <julliard(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #8 from Daniel Ribeiro da Silva <ferion11(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED --- Comment #9 from Alexandre Julliard <julliard(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=49920 m0rvj <johnpgoodman(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johnpgoodman(a)gmail.com --- Comment #10 from m0rvj <johnpgoodman(a)gmail.com> --- I don't think this affects Logos Bible Software any more... is it resolved? I think it could be closed. -- 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.
participants (1)
-
WineHQ Bugzilla