Created attachment 226844 [details] WIP patch, not quite ready yet. Let's track PE build progress here.
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?
(In reply to Gerald Pfeifer from comment #1) Yeah, probably. mingw-64 should more convenient for standalone applications, in case somebody needs that.
Created attachment 226855 [details] [wip] PE build v2 Now with amd64-* -> x86_64-* symlinks.
Created attachment 226906 [details] [wip] PE build v3 Adjusted for 6.14. Also, Wine's current XAudio2 implementation depends on FAudio instead of OpenAL.
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).
(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.
(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.)
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.
(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.
Created attachment 227994 [details] PE build v4
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!
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.)
Created attachment 229341 [details] PE build v5 (against 00078ad233b83f1b5a53355502ba8747480c991f)
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.
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?
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.
Hmm... I suppose we should as well remove FAudio and libxml2 from LIB_DEPENDS due to them being bundled with Wine now.
(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...
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 :-).
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.
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]
For the record, I'm _not_ developing any of this.
Patch committed, thanks Alex, Damjan, and STefan!