Bug 257533 - emulators/wine-devel: PE build
Summary: emulators/wine-devel: PE build
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Gerald Pfeifer
URL:
Keywords:
Depends on: 257020 257651
Blocks:
  Show dependency treegraph
 
Reported: 2021-08-01 15:10 UTC by Alex S
Modified: 2021-09-19 10:35 UTC (History)
3 users (show)

See Also:
gerald: 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

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