I've tested every single version (I don't remember the last working one, probably 6.5 or so), every time it got updated, the same issue occurs. First one: wine: could not load ntdll.so: Cannot open "/usr/local/bin/../lib/wine/x86_64-unix/ntdll.so" Wine is searching for this dll in /usr/local/lib/wine/x86_64-unix, which it doesn't exists, wine64 directories are amd64-unix and amd64-windows and wine wants x86_64-unix and x86-windows. For the test purposes, a symbolic link would be sufficient, but them the next issue will arrive. wine: could not load kernel32.dll, status c0000135 Obs: The proc is mounted and I'm aware of some of the wine-hq tickets, unless there's something more I should try.
Maybe related? bug #255336
(In reply to Daniel Menelkir from comment #0) > wine: could not load ntdll.so: Cannot open "/usr/local/bin/../lib/wine/x86_64-unix/ntdll.so" – bug 257105. I get this in isolation. (I don't get anything about kernel32.dll …)
This cannot be reproduced when building 64 bit Wine outside the Port. Somehow, the top level Makefile contains paths of the form: .../amd64-unix/ntdll.so when building with the Port, and .../x86_64-unix/ntdll.so when building without the Port. Makefiles are generated by tools/makedep.c, which seems to get it from the ARCH environment variable, but that has the right value (x86_64) in config.log even for the Port.
The code is hardcoded to expect "x86_64", and won't work with "amd64" however that comes in: dlls/dbghelp/path.c:static const WCHAR so_dir[] = L"\\x86_64-unix"; dlls/wineandroid.drv/WineActivity.java: if (abi.equals( "x86_64" )) return "/x86_64-unix"; dlls/ntdll/unix/loader.c:static const char so_dir[] = "/x86_64-unix"; loader/main.c:#define SO_DIR "x86_64-unix/"
*** Bug 257105 has been marked as a duplicate of this bug. ***
Created attachment 226830 [details] Proposed patch Does the attached patch (which forward ports recent improvements to the emulators/wine port) improve (or at least change) the situation?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=27ae28dd240c63c37a2fe17d2a2440d1beda5870 commit 27ae28dd240c63c37a2fe17d2a2440d1beda5870 Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2021-08-02 21:40:18 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2021-08-02 21:40:19 +0000 emulators/wine-devel: Invoke with LD_BIND_NOW and revampe WoW Forward port 1d2af6e08958ac78de9fae727283ac8cdaf8705f and its two follow-up fixes ad15b0e748b6bd93ef1e36b1c605c1da29d10565 and 1b5885c463320a2af0e7fe2ed0fdca93d760ad19 from emulators/wine: Wine 6.0 and later need LD_BIND_NOW / LD_32_BIND_NOW on FreeBSD, cf. https://bugs.winehq.org/show_bug.cgi?id=50257 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252307 so move the actual binaries to wine64.bin / wine.bin and invoke them via a script that does those settings. [1] Also revamp the WoW handling/packging which combines 32-bit/i386 Wine into 64-bit/amd64 Wine. [1] Submitted by: Alex S <iwtcex@gmail.com> [1] PR: 257284 [1], 252307 [1], 255336, 257020 emulators/wine-devel/Makefile | 12 ++++++++ emulators/wine-devel/files/pkg32.sh (new) | 15 +++++++++ emulators/wine-devel/files/wine-wow64.sh (new) | 42 ++++++++++++++++++++++++++ emulators/wine-devel/files/wine.sh (new) | 14 +++++++++ emulators/wine-devel/pkg-plist | 8 +++-- 5 files changed, 89 insertions(+), 2 deletions(-)
I believe the commit I just made does not resolve the situation (there is no code that changes to that end from what I can see), though it hopefully is a step towards the better.
(In reply to Damjan Jovanovic from comment #3) It's even funnier than that. makedep generates Makefile with proper (x86_64-) paths on the configure step, then it overwrites those paths right at the start of the build step. Apparently it reads ARCH from the MAKEFLAGS environment variable, which is typically set to something like: w -- _SMP_CPUS=4 _PKG_TRANSITIONING_TO_NEW_EXT=yes _PKG_CHECKED=1 _PERL5_FROM_BIN=5.32.1 _OSRELEASE=13.0-RELEASE OSVERSION=1300139 OSREL=13.0 OPSYS=FreeBSD HAVE_COMPAT_IA32_KERN=YES\ CONFIGURE_MAX_CMD_LEN=524288 BATCH=y ARCH=amd64. There is nothing there that makedep would ever want to read, so we should just patch it like this: post-patch: ${REINPLACE_CMD} 's/"MAKEFLAGS"/"MAKEDEP_MAKEFLAGS"/g' ${WRKSRC}/tools/makedep.c and leave that variable unset. I see no downsides.
Created attachment 226981 [details] amd64 -> x86_64 paths
(In reply to Alex S from comment #10) I'd appreciate a bit more attention here.
(In reply to Alex S from comment #11) > I'd appreciate a bit more attention here. Understood, and I'll see what I can do in the coming days. I've been busy ensuring upstream Wine didn't keep FreeBSD builds failing too much for too long, since once you heap failures on top of failures things deteriorate quickly - about a dozen submissions, all accepted in the last month or two. In addition I don't believe this is the ideal fix, a bit similar to bug #257398 where I worked upstream and got something in place that does not require local patching even.
Patch for makefile fix problem for me.
Comment on attachment 226981 [details] amd64 -> x86_64 paths As I mentioned earlier, I believe is not an ideal fix (among others since it is not upstreamable and does not address the case of building Wine outside the FreeBSD ports collection). It did inspire me, however, for which I am grateful, and I plan on shortly committing what I believe is a better approach that I will also pursue with upstream.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a02e3c6686d68350132a88379fc3d99445b9b80d commit a02e3c6686d68350132a88379fc3d99445b9b80d Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2021-09-16 21:54:47 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2021-09-16 21:57:50 +0000 emulators/wine-devel: Update to Wine 6.17 This includes the following changes: - WineCfg program converted to PE. - Better high-DPI support in builtin applications. - More preparation work for the GDI syscall interface. - Improved debugger support in Wow64 mode. - Various bug fixes. My patch files/patch-dlls-nsiproxy.sys has been accepted upstream, so remove it on our end. Work around FreeBSD calling x86-64 by the name of amd64 and the Ports Collection using this in a variable ARCH, which interferes with Wine's variable of the same name and messes things up badly. I have hope to be able to upstream files/patch-amd64-vs-x86-64. [1] PR: 257020 [1] Inspired by: Ivan Rozhuk <rozhuk.im@gmail.com> [1] emulators/wine-devel/Makefile | 5 ++-- emulators/wine-devel/distinfo | 10 +++---- .../wine-devel/files/patch-amd64-vs-x86-64 (new) | 17 ++++++++++++ .../files/patch-dlls-nsiproxy.sys (gone) | 31 ---------------------- emulators/wine-devel/pkg-plist | 11 ++++++++ 5 files changed, 35 insertions(+), 39 deletions(-)
I believe this addresses the issue. Please advise Daniel, Alex, and Ivan. And apologies Alex for mis-attributing the inspiration in my commit message. :-(
Not fixed.
Thanks for testing, Ivan, and apologies. In GNU terms x86-64 is actually called x86_64. I'm build testing an update as we speak and hope to commit in the next half hour. It would be great could you give that another spin then. Sorry for the false start!
Now works fine, thanks! Are you sure that + ${REINPLACE_CMD} 's/"MAKEFLAGS"/"MAKEDEP_MAKEFLAGS"/g' ${WRKSRC}/tools/makedep.c from patch in this PR is not required?
(In reply to Ivan Rozhuk from comment #19) > Now works fine, thanks! Great, happy to hear that! Thanks for giving it a try and reporting back. > Are you sure that > + ${REINPLACE_CMD} 's/"MAKEFLAGS"/"MAKEDEP_MAKEFLAGS"/g' ${WRKSRC}/tools/makedep.c > > from patch in this PR is not required? My patch is an alternate approach which, unlike the original, hopefully can get accepted upstream and also work outside of the realm of our Ports Collection - just "out of the box". I hope it is sufficient and covers everything necessary.
Hello, this problem now returned with wine-devel 7.22 Alexander88207@Home:~ $ wineboot wine: created the configuration directory '/home/Alexander88207/.wine' 0024:fixme:ntdll:create_logical_proc_info stub 0024:fixme:ntdll:init_cpu_info Failed to get logical processor information, status 0xc0000002. 002c:fixme:ntdll:create_logical_proc_info stub 002c:fixme:ntdll:init_cpu_info Failed to get logical processor information, status 0xc0000002. wine: failed to open L"C:\\windows\\system32\\wineboot.exe": c0000135 0024:err:environ:run_wineboot failed to start wineboot c0000135 wine: could not load kernel32.dll, status c0000135