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
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?
> 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
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:
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:
2. Even the --enable-win64 ELF build of Wine with Clang 11 dies with:
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*);
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:
Author: Alexandre Julliard <firstname.lastname@example.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:
Author: Damjan Jovanovic <email@example.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 .
PR: 257533 
Submitted by: Alex S <firstname.lastname@example.org> 
For the record, I'm _not_ developing any of this.
Patch committed, thanks Alex, Damjan, and STefan!