[Bug 50461] New: Wine looking in /usr/bin/../../lib32/wine, should be /usr/bin/../lib32/wine
https://bugs.winehq.org/show_bug.cgi?id=50461 Bug ID: 50461 Summary: Wine looking in /usr/bin/../../lib32/wine, should be /usr/bin/../lib32/wine Product: Wine Version: 5.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: bebing2(a)optimum.net Distribution: --- Previous version I was using, 4.19 staging, builds and installs fine. 5.20 when launching anything, but winecfg will trigger it, gets this: wine: could not load ntdll.so: /usr/bin/../../lib32/wine/ntdll.so: cannot open shared object file: No such file or directory Which resolves to root directory /lib32 but should resolve to /usr/lib32 Looks like it usually is /usr/bin/../lib32 not /usr/bin/../../lib32 I use LFS so it is likely it is not conforming to debian/ubuntu or whatever. I have a thread here where I tried some hacks to workaround to no avail, just in case it's useful: https://forum.winehq.org/viewtopic.php?f=8&t=34780 -- 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=50461 --- Comment #1 from bebing2(a)optimum.net --- Oh yeah, it doesn't seem like it was right to pick ntdll.so, but since it happens to be the what exposed the error I selected that. This seems like a ./configure issue Here are my procedures after installing wine-staging: cd /usr/src/wine-5.20 mkdir wine64-build cd wine64-build ../configure \ --sysconfdir=/etc \ --localstatedir=/var \ --libdir=/usr/lib64 \ --enable-win64 \ --without-gstreamer \ --without-oss \ --without-xrandr \ --without-xxf86vm make cd .. mkdir wine32-build cd wine32-build PKG_CONFIG_PATH=/usr/lib32/pkgconfig ../configure \ --sysconfdir=/etc \ --localstatedir=/var \ --libdir=/usr/lib32 \ --without-gstreamer \ --without-oss \ --without-xrandr \ --without-xxf86vm \ --with-wine64=../wine64-build make as root cd /usr/src/wine-5.20 cd wine32-build make install cd ../wine64-build make install winecfg -- 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=50461 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek(a)codeweavers.com --- Comment #2 from Jacek Caban <jacek(a)codeweavers.com> --- Please try adding --prefix=/usr to configure. -- 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=50461 --- Comment #3 from bebing2(a)optimum.net --- That was my first thought! Tried it and winecfg couldn't start with violation/exception of 000000000:000000000. I didn't capture the output, but can do it again. Unfortunately I will be tied-up for the next couple of hours. -- 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=50461 --- Comment #4 from bebing2(a)optimum.net --- Scrolled up and buffer still had it: winecfg 002c:fixme:winediag:LdrInitializeThunk wine-staging 5.20 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. wine: Unhandled page fault on execute access to 0000000000000000 at address 0000000000000000 (thread 0050), starting debugger... wine: Unhandled page fault on execute access to 0000000000000000 at address 0000000000000000 (thread 0090), starting debugger... ^C0034:err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting 0034:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\winemenubuilder.exe" failed, status c000013a 00ac:err:module:DelayLoadFailureHook failed to delay load comctl32.dll.InitCommonControlsEx wine: Call from 000000007B031316 to unimplemented function comctl32.dll.InitCommonControlsEx, aborting -- 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=50461 --- Comment #5 from Austin English <austinenglish(a)gmail.com> --- Could you try with 6.0-rc5? -- 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=50461 --- Comment #6 from bebing2(a)optimum.net --- You bet! Thanks, will update here shortly... -- 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=50461 --- Comment #7 from bebing2(a)optimum.net --- It's still happening in wine-6.0-rc5 with wine-staging-6.0-rc5: wine: could not load ntdll.so: /usr/bin/../../lib32/wine/ntdll.so: cannot open shared object file: No such file or directory This is without --prefix=/usr which I have never used in the past for wine. Should I do a non-staging build? Thanks for looking at this. -- 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=50461 --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> --- The default prefix is /usr/local, so if you specify --libdir=/usr/lib Wine will correctly expect the libdir to be at ../../lib relative to the bin directory. make install will also put the binaries in /usr/local/bin, and if you run from there everything should work. If you are going to install the binaries in /usr/bin you need --prefix=/usr. I don't see any bug here. -- 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=50461 --- Comment #9 from bebing2(a)optimum.net --- It didn't work that way in 4.19, or I should say I don't observe that behavior when building and installing 4.19-staging which I verified earlier today. -- 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=50461 --- Comment #10 from bebing2(a)optimum.net --- Also, as I explained in the other thread, on my system I don't have /usr/local or I should say /usr/local -> /usr. As an experiment I removed my links, did the install, manually moved everything from /usr/local to /usr, then restored the links. Wine at least up until 4.19 would let me run this way. Run out of /usr so to speak. Are you saying that starting at some point before or at 5.10 you cannot run the way I used to any more and I have to have a /usr/local and update my PATH? -- 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=50461 --- Comment #11 from bebing2(a)optimum.net --- 5.20 I meant. -- 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=50461 --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- In older versions it may have located libwine through the standard library search path, thus hiding the incorrect configuration. Since we no longer use libwine, it's now necessary to run configure with correct paths. You don't need a /usr/local, simply use --prefix=/usr, or alternatively --libdir=/usr/local/lib32, so that the bin and lib dir are correct relative to each other. -- 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=50461 --- Comment #13 from bebing2(a)optimum.net --- Hmm, I've gone 20 years not having a /usr/local and it was bliss. I guess those days are over. Building with --prefix=/usr produces this runtime error: winecfg 002c:fixme:winediag:LdrInitializeThunk wine-staging 5.20 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. wine: Unhandled page fault on execute access to 0000000000000000 at address 0000000000000000 (thread 0050), starting debugger... wine: Unhandled page fault on execute access to 0000000000000000 at address 0000000000000000 (thread 0090), starting debugger... ^C0034:err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting 0034:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\winemenubuilder.exe" failed, status c000013a 00ac:err:module:DelayLoadFailureHook failed to delay load comctl32.dll.InitCommonControlsEx wine: Call from 000000007B031316 to unimplemented function comctl32.dll.InitCommonControlsEx, aborting -- 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=50461 --- Comment #14 from bebing2(a)optimum.net --- I don't think I will change my ways at this point. I will take the hit and will fall back to 4.19. Thanks anyway. -- 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=50461 --- Comment #15 from bebing2(a)optimum.net --- Oh! I think I misunderstood. I can leave my /usr/local -> /usr link if I pass in --libdir=/usr/local/lib32? If so, I will definitely do that. I guess do it for both the 32 bit and the 64 bit build? --libdir=/usr/local/lib64 \ and --libdir=/usr/local/lib32 \ That would be fine by me if I get to keep the /usr/local link. -- 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=50461 --- Comment #16 from bebing2(a)optimum.net --- Wouldn't it be the bin directory that would be /usr/local/bin then ../../lib32 would take you to /usr/lib32, right? -- 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=50461 --- Comment #17 from bebing2(a)optimum.net --- Nevermind I think you were right the first time. I'll just try it... -- 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=50461 --- Comment #18 from bebing2(a)optimum.net --- Also posting this for informational purposes: http://www.linuxfromscratch.org/blfs/view/svn/introduction/position.html -- 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=50461 --- Comment #19 from bebing2(a)optimum.net --- Adding the following causes a run-time crash --libdir=/usr/local/lib64 --libdir=/usr/local/lib32 I am going to try --bindir=/usr/local/bin and leave --libdir=/usr/lib64 \ and --libdir=/usr/lib32 \ as is... It seems to make sense /usr/local/bin/../../lib32/wine/ntdll.so would cause it to match it theory, fingers crossed. -- 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=50461 --- Comment #20 from bebing2(a)optimum.net --- --bindir=/usr/local/bin Bah, that didn't work: wine: could not load ntdll.so: /usr/bin/../../lib32/wine/ntdll.so: cannot open shared object file: No such file or directory Oh well, no biggie, I will fall back to 4.19. The reason I migrated was because World of Warcraft opening cinematic causes a crash in 4.19, but everything else works, which is probably 50 programs or so. Steam also works fine. Thanks for this awesome program, I don't know how you guys do it! -- 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=50461 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #21 from Alexandre Julliard <julliard(a)winehq.org> --- The runtime crash is a different issue, if you get that far it means that the paths are correct. Anyway, closing then. -- 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=50461 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #22 from Austin English <austinenglish(a)gmail.com> --- Closing. -- 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=50461 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED --- Comment #23 from Austin English <austinenglish(a)gmail.com> --- Closing. -- 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=50461 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #24 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Closing INVALID. -- 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