Bug 257533 - emulators/wine-devel: PE build
Summary: emulators/wine-devel: PE build
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Damjan Jovanovic
URL:
Keywords:
Depends on: 257020 257651
Blocks:
  Show dependency treegraph
 
Reported: 2021-08-01 15:10 UTC by Alex S
Modified: 2022-02-01 10:43 UTC (History)
7 users (show)

See Also:
damjan.jov: maintainer-feedback+


Attachments
WIP patch, not quite ready yet. (66.52 KB, patch)
2021-08-01 15:10 UTC, Alex S
no flags Details | Diff
[wip] PE build v2 (67.13 KB, patch)
2021-08-01 18:55 UTC, Alex S
no flags Details | Diff
[wip] PE build v3 (70.57 KB, patch)
2021-08-03 09:01 UTC, Alex S
no flags Details | Diff
PE build v4 (64.34 KB, patch)
2021-09-18 20:34 UTC, Alex S
no flags Details | Diff
PE build v5 (against 00078ad233b83f1b5a53355502ba8747480c991f) (66.78 KB, patch)
2021-11-07 10:38 UTC, Alex S
no flags Details | Diff
PE build v6 (against 1f883daf79d69aaf869dd6e589bb2dbbac190115) (69.30 KB, patch)
2022-01-23 05:38 UTC, Alex S
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex S 2021-08-01 15:10:46 UTC
Created attachment 226844 [details]
WIP patch, not quite ready yet.

Let's track PE build progress here.
Comment 1 Gerald Pfeifer freebsd_committer 2021-08-01 15:19:24 UTC
Does this obsolete the need for devel/mingw-w64 cross compilers
per https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237213
at least as far as Wine is concerned?
Comment 2 Alex S 2021-08-01 15:23:44 UTC
(In reply to Gerald Pfeifer from comment #1)

Yeah, probably. mingw-64 should more convenient for standalone applications, in case somebody needs that.
Comment 3 Alex S 2021-08-01 18:55:06 UTC
Created attachment 226855 [details]
[wip] PE build v2

Now with amd64-* -> x86_64-* symlinks.
Comment 4 Alex S 2021-08-03 09:01:11 UTC
Created attachment 226906 [details]
[wip] PE build v3

Adjusted for 6.14. Also, Wine's current XAudio2 implementation depends on FAudio instead of OpenAL.
Comment 5 Gerald Pfeifer freebsd_committer 2021-08-10 07:52:22 UTC
The stdarg.h change seems very wrong somehow. I don't know what is going
on, but something like this should not be necessary (and we definitely 
should not copy in stdarg.h from anywhere and use the compiler provided).
Comment 6 Alex S 2021-08-10 07:59:35 UTC
(In reply to Gerald Pfeifer from comment #5)

Did you pay attention to https://bugs.winehq.org/show_bug.cgi?id=50257#c38? It *is* a compiler provided stdarg.h, which is normally supposed to be somewhere in llvm package. I have no idea why it's missing and I'm not going to fight the port maintainers over it.
Comment 7 Gerald Pfeifer freebsd_committer 2021-08-10 09:08:09 UTC
(In reply to Alex S from comment #6)
> Did you pay attention to https://bugs.winehq.org/show_bug.cgi?id=50257#c38?

Yes.

> It *is* a compiler provided stdarg.h, which is normally supposed to be
> somewhere in llvm package. I have no idea why it's missing and I'm not
> going to fight the port maintainers over it.

Have you simply asked them? Brought it to their attention?

(Nobody suggested you fight anyone, and I don't think that would be
necessary.)
Comment 8 Gerald Pfeifer freebsd_committer 2021-08-10 09:08:57 UTC
For, what version of stdarg.h may be working well now, with a certain
compiler version, may not be working with a different compiler version.
Comment 9 Alex S 2021-08-10 16:37:17 UTC
(In reply to Gerald Pfeifer from comment #7)

> Have you simply asked them? Brought it to their attention?

My intuition tells me they know about it (but not necessarily that it's critical for cross-compilation). Anyway, I just found some tangential discussion at https://reviews.freebsd.org/D17002?id=47613#506769. Looks rather meh.


(In reply to Gerald Pfeifer from comment #8)

> For, what version of stdarg.h may be working well now, with a certain compiler version, may not be working with a different compiler version.

While this a valid concern in general, that header provides macros for a bunch of __builtin symbols, so there is a reasonably low risk of breakage.
Comment 10 Alex S 2021-09-18 20:34:21 UTC
Created attachment 227994 [details]
PE build v4
Comment 11 Gerald Pfeifer freebsd_committer 2021-09-30 06:26:37 UTC
I relinquished maintainership of wine-devel; pass to emulation@.

The stdarg.h patch still seems like it's the wrong place to address (this
should be something for the LLVM packages to address).

Generally this - moving to PE - is something Wine upstream appears to be
moving towards, where the drivers also reached out to Linux distributions
to move in that direction, so something to pursue. Thank you!
Comment 12 Gerald Pfeifer freebsd_committer 2021-10-28 07:58:14 UTC
Over to new maintainer.

(Not suggesting to push this into the current snapshot already in the works
or the next, both of which will see a fair bit of changes.)
Comment 13 Alex S 2021-11-07 10:38:47 UTC
Created attachment 229341 [details]
PE build v5 (against 00078ad233b83f1b5a53355502ba8747480c991f)
Comment 14 Val Packett 2022-01-19 18:59:46 UTC
We hit the same llvm package thing with wasi-libc, we ended up providing the llvm stdarg.h (and stddef.h) in files/ too:

https://github.com/freebsd/freebsd-ports/tree/46e348be07c024d1bd25f1e0a965ce13cd4aaf35/devel/wasi-libc/files

IIRC there was an actual reason for llvm ports to exclude these headers.
Comment 15 Gerald Pfeifer freebsd_committer 2022-01-22 00:43:22 UTC
Is this still necessary/desirable after the upstream work leading 
to Wine 7?

If so, with Wine 7 out, maybe a good opportunity to switch wine-devel
to this new build?
Comment 16 Alex S 2022-01-23 05:38:17 UTC
Created attachment 231244 [details]
PE build v6 (against 1f883daf79d69aaf869dd6e589bb2dbbac190115)

I fail to see how alignment with upstream would ever be not desirable. Here's an updated patch. Verifying plist changes took me 2 hours, so I'd rather not do this again.
Comment 17 Alex S 2022-01-25 11:33:42 UTC
Hmm... I suppose we should as well remove FAudio and libxml2 from LIB_DEPENDS due to them being bundled with Wine now.
Comment 18 Gerald Pfeifer freebsd_committer 2022-01-28 07:40:06 UTC
(In reply to Alex S from comment #17)
> Hmm... I suppose we should as well remove FAudio and libxml2
> from LIB_DEPENDS due to them being bundled with Wine now.

Yes, I did wonder towards Damjan a bit before you made this note.
That's a quick change we can make...
Comment 19 Damjan Jovanovic 2022-01-30 10:05:26 UTC
Very impressive work Alex. I expected a huge new llvm-mingw package or something, and massive changes to emulators/wine-devel, I can't believe how few changes were needed in the end.

Clang doesn't have a good history with Wine. There are a number of clang-specific Wine issues, as some examples:

1. https://bugs.winehq.org/show_bug.cgi?id=48265

2. Even the --enable-win64 ELF build of Wine with Clang 11 dies with:
---snip---
dlls/ntoskrnl.exe/sync.c:829:13: error: function declared 'ms_abi' here was previously declared 'cdecl'
void WINAPI ExAcquireFastMutex( FAST_MUTEX *mutex )
            ^
include/ddk/wdm.h:1653:18: note: previous declaration is here
void    FASTCALL ExAcquireFastMutex(FAST_MUTEX*);
---snip---
whereas GCC succeeds.

Clang seems too fragile and incompatible. It's great for our base system, where we can adapt our code to it, but Ports have specialized needs. It's not just Wine, OpenOffice/LibreOffice also crash in certain places when built with Clang, due to its inability to pass through undeclared C++ exceptions; GCC has a command line option to allow that (-fno-enforce-eh-specs).

However the PE build would really help, it's required for debugging https://bugs.winehq.org/show_bug.cgi?id=52447 (the relevant unit test only works on the PE build), and wine-devel is a "-devel" branch after all ;-), so I am going to accept it into 7.1.

I've had to make these changes:

1. Doesn't package, because as of this commit:
commit 1077a5bd9943bd89eb520ed2938992112a0dd58c
Author: Alexandre Julliard <julliard@winehq.org>
Date:   Wed Jan 26 13:20:42 2022 +0100

we no longer have a mfmediaengine.a

2. ===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: include/wine/windows/trnlcl.idl
Error: Orphaned: include/wine/windows/trnobj.idl
Error: Orphaned: lib/wine/%%WINEARCH%%-unix/libmsvcp140.a
Error: Orphaned: lib/wine/%%WINEARCH%%-windows/libmsvcp140.a
Error: Orphaned: lib/wine/%%WINEARCH%%-windows/msvcp140_atomic_wait.dll
Error: Orphaned: lib/wine/%%WINEARCH%%-windows/wmadmod.dll

Added those too.

Thank you so much Alex :-).
Comment 20 Alex S 2022-01-30 13:15:04 UTC
Forgot to mention that LD_BIND_NOW=1 workaround is not necessary for
the PE build, so we can remove it as well.

(In reply to Damjan Jovanovic from comment #19)

> I expected a huge new llvm-mingw package or something, and massive
> changes to emulators/wine-devel

That is because Wine (the project) already took care of it. I'm just
following https://bugs.winehq.org/show_bug.cgi?id=50257#c36 there.

> Clang seems too fragile and incompatible.

We'll see. I didn't notice any issues specific to the PE build. It's
a bit of a bummer that we still can't build the rest of Wine with
Clang (and I expect a lot complaints about dual gcc/llvm dependency
there), but this mostly reflects our resources, rather than Clang
being a particularly weird compiler.

In any case, there is a good chance those Clang compilation bugs might
not be applicable to Wine's "new WoW64 architecture", so we should
simply focus on that.
Comment 21 commit-hook freebsd_committer 2022-02-01 07:50:23 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=1c0bf4fc52b30f6cad536c3f954c156eba08369e

commit 1c0bf4fc52b30f6cad536c3f954c156eba08369e
Author:     Damjan Jovanovic <damjan.jov@gmail.com>
AuthorDate: 2022-02-01 07:44:44 +0000
Commit:     Gerald Pfeifer <gerald@FreeBSD.org>
CommitDate: 2022-02-01 07:48:29 +0000

    emulators/wine-devel: Update to Wine 7.1 (commit message)

    The original commit ( 739b9ddcf5b07a3d4549f5a217534f4e3d1bbcd0 )
    somehow lost the commit message; make up for this thusly.

    This includes the following changes:
     - Vulkan 1.3 support.
     - A number of theming fixes.
     - WebSocket improvements.
     - Improved cursor clipping on macOS.
     - IDL compiler fixes for C++.
     - Various bug fixes.

    This is also the first version of this Port that does a "PE build",
    where most DLLs and internal applications (eg. winedbg) are
    cross-compiled to actual Windows .dll and .exe file formats (some
    of which even work on Windows itself), instead of the PE-in-ELF
    .dll.so files that the "ELF build" provides. This provides greater
    compatibility with copy protection and anti-cheat systems that
    examine binary files' internal structure, better unit testing, and
    will eventually allow a strong guest<->host separation, where
    Windows binaries run in one environment and call out to a completely
    foreign environment below, switching stacks (if not address spaces)
    during each call, eg. Win32 binaries could run on amd64 or Aarch64
    with no i386 dependencies needed on the underlying system, along
    similar lines to what "hangover" already does. A big thank you
    to Alex for developing and testing this difficult feature [1].

    PR:             257533 [1]
    Submitted by:   Alex S <iwtcex@gmail.com> [1]
Comment 22 Alex S 2022-02-01 10:15:43 UTC
For the record, I'm _not_ developing any of this.
Comment 23 Gerald Pfeifer freebsd_committer 2022-02-01 10:43:19 UTC
Patch committed, thanks Alex, Damjan, and STefan!