Bug 237213 - [NEW PORT] devel/mingw-w64 cross compilers
Summary: [NEW PORT] devel/mingw-w64 cross compilers
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs mailing list
Keywords: patch
Depends on:
Reported: 2019-04-12 04:24 UTC by Damjan Jovanovic
Modified: 2020-03-09 20:43 UTC (History)
8 users (show)

See Also:

MinGW-w64 for Windows cross-development using LLVM/Clang (469.84 KB, patch)
2020-03-01 08:18 UTC, Theron Tarigo
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Damjan Jovanovic 2019-04-12 04:24:31 UTC

Can someone please make a port for the mingw-w64 project that cross-compiles Windows binaries from *nix?

Note that this is NOT THE SAME software project as the now largely abandoned mingw project; mingw-w64 was made by different developers with a different setup, and (despite the name) can build both Win32 and Win64 binaries unlike the original mingw project that only supported Win32.

I need this to develop Wine-Mono on FreeBSD, and it is generally useful in all cases where mingw was useful. Please provide both the Win32 and Win64 ports.


Thank you so much!
Comment 1 Naram Qashat 2019-09-06 02:13:04 UTC
I've been wanting to do this on-and-off for probably a few years now, but the documentation for it, which you linked, is pretty lackluster and a bit confusing at points. I've not had the time to really dive into it much either.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-16 11:55:01 UTC
@Naram / Akinori-san, is this something either one of you can take care of?

Normally, Bugzilla is not used to take new port requests, in favour of creating entries in the wiki [1]

[1] https://wiki.freebsd.org/WantedPorts

If we can get some buy-in to create these ports, I'm happy to keep the issue open.

Separately there is also the question of maintainer/maintenance. Our mingw* ports aren't in the best shape with regard to maintenance (I may be wrong with regard to versions being up to date however)
Comment 3 Naram Qashat 2019-09-16 12:58:37 UTC
You're right about the current mingw ports not being in the best shape, I haven't devoted time to them as I feel that the current mingw ports are outdated and stale. Maybe it's just my opinion on them. I'd love to have the mingw-w64 project in the ports tree instead of what we currently have, but as I mentioned previously, I have not devoted any time to looking into how to get those into the ports tree either.
Comment 4 Alex S 2019-11-10 08:20:47 UTC
Might be useful for Proton as well.

(In reply to Kubilay Kocak from comment #2)

> If we can get some buy-in to create these ports
That doesn't sound encouraging. Who's permission we should ask first? I'd hate to put 100+ hours into something only to see it stalled at review/merge level.
Comment 5 Alex S 2019-11-10 08:27:50 UTC
(In reply to Alex S from comment #4)

* whose

(f* Bugzilla and it's lack of edit function)
Comment 6 Theron Tarigo freebsd_committer 2020-02-29 01:40:05 UTC
(In reply to Alex S from comment #4)
Uhoh.  Why 100+ hours for this?  Why should this get bogged in review (I don't see anything likely controversial here)?

> If we can get some buy-in to create these ports

I think all this means is someone needs to volunteer to do the work.  I'm looking into it a bit right now.

My experience with not getting things accepted is failing to make enough noise to get committers' attention (or some would say, failing to become a committer myself).
Comment 7 Alex S 2020-02-29 10:35:48 UTC
(In reply to Theron Tarigo from comment #6)

See https://aur.archlinux.org/packages/mingw-w64-gcc and https://github.com/ValveSoftware/Proton/blob/proton_5.0/build-mingw-w64.sh for reference.

You can also look at my half-assed attempt at building mingw-w64: https://gist.github.com/shkhln/bfefeb1196707559a5de0e1290edc37a. Although I'm not sure if that's actually useful.

> Why 100+ hours for this?

Getting reasonably familiar with the gcc building process, waiting for compilation to finish (multiple times, of course), debugging compilation errors (such as undefined reference to `___chkstk_ms' for example).
Comment 8 Theron Tarigo freebsd_committer 2020-03-01 08:18:34 UTC
Created attachment 212067 [details]
MinGW-w64 for Windows cross-development using LLVM/Clang

This ended up being not difficult, albeit using LLVM toolchain, thanks to https://github.com/mstorsjo/llvm-mingw .

Of course getting everything done, compiling a working Windows 64bit exe, and seemingly ready to upload the patch only took half the time, other half has been wasted tracking down ridiculous behaviors whereby Clang tries to use GCC-4.x junk instead of its own libraries if the ancient mingw32-* packages are left installed... At least the fix ended up being simple.

When will these developers learn that adding automated workaround disasters and not documenting them prominently wastes more time than simple errors in the edge-cases they are meant to "fix"?

Needs commit or review (I'll put it in the mailing list if no one sees this).
Comment 9 Alex S 2020-03-01 08:52:52 UTC
Oh, I wasn't aware of that project. Clang is much easier to deal with. Good job, I suppose.
Comment 10 Theron Tarigo freebsd_committer 2020-03-01 09:08:12 UTC
(In reply to Alex S from comment #9)
We shall see.  As noted in that project's README, existing MinGW projects with portability shortcomings will have problems with the usual GNU vs LLVM toolchain differences.

That won't affect me since I start my projects on FreeBSD and then port to other platforms, but someone else could look into supporting more GNU tools without necessarily switching to GCC.