Bug 257020 - emulators/wine-devel: could not load kernel32.dll, status c0000135
Summary: emulators/wine-devel: could not load kernel32.dll, status c0000135
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Gerald Pfeifer
URL:
Keywords:
: 257105 (view as bug list)
Depends on:
Blocks: 257533
  Show dependency treegraph
 
Reported: 2021-07-06 12:24 UTC by Daniel Menelkir
Modified: 2021-09-17 14:21 UTC (History)
6 users (show)

See Also:


Attachments
Proposed patch (6.09 KB, patch)
2021-08-01 09:53 UTC, Gerald Pfeifer
no flags Details | Diff
amd64 -> x86_64 paths (1015 bytes, patch)
2021-08-06 07:11 UTC, Alex S
gerald: maintainer-approval-
gerald: maintainer-approval-
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Menelkir 2021-07-06 12:24:35 UTC
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.
Comment 1 Daniel Menelkir 2021-07-06 12:30:32 UTC
Maybe related? bug #255336
Comment 2 Graham Perrin 2021-07-12 01:00:14 UTC
(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 …)
Comment 3 Damjan Jovanovic 2021-07-12 18:13:31 UTC
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.
Comment 4 Damjan Jovanovic 2021-07-13 00:16:44 UTC
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/"
Comment 5 Gerald Pfeifer freebsd_committer 2021-07-22 22:25:47 UTC
*** Bug 257105 has been marked as a duplicate of this bug. ***
Comment 6 Gerald Pfeifer freebsd_committer 2021-08-01 09:53:49 UTC
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?
Comment 7 commit-hook freebsd_committer 2021-08-02 21:43:36 UTC
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(-)
Comment 8 Gerald Pfeifer freebsd_committer 2021-08-02 21:45:12 UTC
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.
Comment 9 Alex S 2021-08-06 06:43:03 UTC
(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.
Comment 10 Alex S 2021-08-06 07:11:39 UTC
Created attachment 226981 [details]
amd64 -> x86_64 paths
Comment 11 Alex S 2021-08-20 17:24:43 UTC
(In reply to Alex S from comment #10)

I'd appreciate a bit more attention here.
Comment 12 Gerald Pfeifer freebsd_committer 2021-09-09 15:13:35 UTC
(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.
Comment 13 Ivan Rozhuk 2021-09-12 20:04:18 UTC
Patch for makefile fix problem for me.
Comment 14 Gerald Pfeifer freebsd_committer 2021-09-16 21:39:32 UTC
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.
Comment 15 commit-hook freebsd_committer 2021-09-16 21:58:52 UTC
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(-)
Comment 16 Gerald Pfeifer freebsd_committer 2021-09-16 22:03:34 UTC
I believe this addresses the issue.

Please advise Daniel, Alex, and Ivan.

And apologies Alex for mis-attributing the inspiration in my commit
message. :-(
Comment 17 Ivan Rozhuk 2021-09-17 13:23:32 UTC
Not fixed.
Comment 18 Gerald Pfeifer freebsd_committer 2021-09-17 14:21:22 UTC
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!