Hi 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. Links: https://mingw-w64.org/doku.php/download https://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/ Thank you so much!
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.
@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)
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.
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.
(In reply to Alex S from comment #4) * whose (f* Bugzilla and it's lack of edit function)
(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).
(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).
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).
Oh, I wasn't aware of that project. Clang is much easier to deal with. Good job, I suppose.
(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.
I really needed GCC-based mingw for building Wine and its unit tests, and found a way to get Debian Buster's mingw-w64 version 8.3 working using our Linuxulator and debootstrap: https://forums.freebsd.org/threads/mingw-w64-from-linuxulated-debian-buster-building-wine-pe.76580/
Created attachment 219875 [details] partial port of i686 mingw-w64 So that Debian emulated mingw-w64 crashes a lot and I got sick of it. Here is a partial port from NetBSD's pkg-src's mingw-w64 (https://github.com/NetBSD/pkgsrc/tree/trunk/cross/mingw-w64) to our ports. So far binutils, headers, gcc-bootstrap and crt successfully build. Unfortunately, the last and most important piece, the full gcc build, fails with: ld: error: unable to find library -lc while building libgcc, and I have no idea why. If anyone can help, it would be much appreciated. Apply patch. cd /usr/ports/devel/i686-w64-mingw32-gcc make stage
(In reply to Damjan Jovanovic from comment #12) Try USE_GCC=10.
> # --enable-initfini-array \ > CONFIGURE_ARGS+=--target=${GCC_TARGET} --disable-nls --enable-languages=c,lto,c++,objc,obj-c++,fortran \ This isn't nice either.
(In reply to Alex S from comment #14) I think i686-w64-mingw32-crt needs SSP_UNSAFE=yes. > PKGNAMEPREFIX= i686-w64-ming32- Another typo.
Thank you Alex. USE_GCC=10 and SSP_UNSAFE=yes give different results, but all break in different ways: gcc- | | | bootstrap|crt |gcc |RESULT ---------+--------------+-------------------------------+---------------------- clang |default |clang with |some __stack_check | |--enable-gnu-indirect-function |failure | |--enable-initfini-array | ---------+--------------+-------------------------------+---------------------- clang |default |clang |ld: error: unable to | | | find library -lc ---------+--------------+-------------------------------+---------------------- clang |default |gcc |C++ errors ---------+--------------+-------------------------------+---------------------- clang |USE_GCC=10 and| |CRT fails to link |SSP_UNSAFE=yes| | ---------+--------------+-------------------------------+---------------------- clang |default and |gcc |C++ errors |SSP_UNSAFE=yes| | ---------+--------------+-------------------------------+---------------------- gcc |default and |gcc |C++ errors |SSP_UNSAFE=yes| | ---------+--------------+-------------------------------+---------------------- Those C++ errors happen while building gcov, and look like this: /usr/local/bin/ld: gcov.o: in function `void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) [clone .isra.0]': gcov.c:(.text+0xf4a): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)' /usr/local/bin/ld: gcov.c:(.text+0xf76): undefined reference to `std::__throw_logic_error(char const*)' /usr/local/bin/ld: gcov.o: in function `output_line_beginning(__sFILE*, bool, bool, bool, long, unsigned int, char const*, char const*, unsigned int)': gcov.c:(.text+0x233e): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)' /usr/local/bin/ld: gcov.c:(.text+0x241c): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)' and many more.
(In reply to Damjan Jovanovic from comment #16) Let me try to explain comment #14 again: # ... \ <-- commented out line CONFIGURE_ARGS=... <-- continuation of the same line, CONFIGURE_ARGS is also commented out
It builds successfully when I fix that line, even using Clang for all the parts, and compiles executables that work in Wine. Thank you so so so much Alex! .ssSSSSss. .ER' `AM. .ST' `CS. .E' .S. .S. `S. .L' SSS SSS `S. S' `S' `S' `S S S S S S. s. .s S `S. `"s. .s"' S' `S. `"ss..ss"' .S' `SS. ~~ .SS' `SS. .SS' `SSssssSS' Let me do some cleanup, testing, tweaking, and the ports targeting Win64, then I'll submit a patch for inclusion in Ports.
Created attachment 220001 [details] complete mingw-w64 port Here is my complete mingw-w64 Port, which I am submitting with me as the maintainer. You can install devel/mingw-w64-gcc, with FLAVOR=i686 to target Win32 or FLAVOR=amd64 to target Win64. The GCC binaries are named i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc, like on other *nix platforms. binutils is patched to expose its i686-w64-mingw32 and x86_64-w64-mingw32 targets, which it already had but we never used. mingw-w64 provides the headers and CRT, while GCC 10 provides the bootstrap GCC (to build the CRT) and full GCC. All 5 Ports build and work on both amd64 and i386 hosts. The PE build of the whole of i386-wine (5 million lines of code) was successfully compiled with the i686-mingw-w64-gcc port, and worked fully with all the Windows applications I tested. ******* WARNING ******* Other Ports, whose software auto-detects mingw-w64 and automatically uses it, will break with this Port installed, as they may start producing files unexpected by their pkg-plist. Eg. Wine, since version 5.0, preferentially makes PE builds with mingw-w64 (instead of ELF builds with native CC), and will build successfully but probably fail to package/install as its pkg-plist expects .dll.so files while it produces .dll with mingw-w64 instead. You can (1) force Wine to ignore mingw-w64 with "./configure --without-mingw", or better yet (2) update the Wine ports to use different pkg-plist files depending on whether mingw-w64 is used. (In my test, I built Wine directly from source, not the Port.)
As a minor detail, new ports don't carry PORTREVISION. Is there a specific reason you don't autogenerate pkg-plist like the lang/gcc* ports do? Wouldn't it be easier to have one pkg-plist, not one per architecture? Substitutions might help with that, and if there is a specific issue you ran into, perhaps I (or others) have an idea? More generally, how hard would it be to use the existing lang/gcc10 port, like you have been doing with binutils? (Note: I simply don't have the bandwidth to do a final review or commit, merely trying to help - and hoping someone will step up for the other aspects.)
(In reply to Gerald Pfeifer from comment #20) > As a minor detail, new ports don't carry PORTREVISION. Thank you, fixed. > Is there a specific reason you don't autogenerate pkg-plist like the > lang/gcc* ports do? Because I learned from the bad pkg-plist practices in devel/binutils instead. > More generally, how hard would it be to use the existing lang/gcc10 > port, like you have been doing with binutils? It looked to me like lang/* are for host-targeting compilers, while devel/* are for cross-compilers (devel/powerpc64-gcc, devel/gcc-arm-embedded, etc.). If that's not the case, then maybe lang/gcc10 should be used as the GCC for mingw-w64.
A commit references this bug: Author: gerald Date: Sun Nov 29 11:31:30 UTC 2020 New revision: 556564 URL: https://svnweb.freebsd.org/changeset/ports/556564 Log: Wine is now able to use mingw-w64 to build components. When mingw-w64 is installed on FreeBSD, users might inadvertedly use that when we have not set up things properly yet (and it probably should be an option to choose, at least initially). For example, mingw-w64 produces .dll files instead of the current .dll.so files, breaking pkg-plist. So for now explicitly disable the use of mingw-w64. In a next step, once mingw-w64 is available, we probably should make this an option. PR: 237213 Reported by: Damjan Jovanovic <damjan.jov@gmail.com> MFH: 2020Q4 (blanket: build issue) Changes: head/emulators/wine-devel/Makefile
A commit references this bug: Author: gerald Date: Fri Dec 11 20:38:16 UTC 2020 New revision: 557762 URL: https://svnweb.freebsd.org/changeset/ports/557762 Log: MFH: r556564 Wine is now able to use mingw-w64 to build components. When mingw-w64 is installed on FreeBSD, users might inadvertedly use that when we have not set up things properly yet (and it probably should be an option to choose, at least initially). For example, mingw-w64 produces .dll files instead of the current .dll.so files, breaking pkg-plist. So for now explicitly disable the use of mingw-w64. In a next step, once mingw-w64 is available, we probably should make this an option. PR: 237213 Reported by: Damjan Jovanovic <damjan.jov@gmail.com> Changes: _U branches/2020Q4/ branches/2020Q4/emulators/wine-devel/Makefile
Created attachment 220663 [details] complete mingw-w64 port, version 2 Here is version 2 of the patch adding mingw-w64 ports. PORTREVISION has been removed. pkg-plists have been merged or removed. GCC now comes from a FLAVOR of lang/gcc10, so you can install everything through eg. "FLAVOR=i686_w64_mingw32 make install" in lang/gcc10.
A commit references this bug: Author: gerald Date: Fri Dec 25 12:16:27 UTC 2020 New revision: 559237 URL: https://svnweb.freebsd.org/changeset/ports/559237 Log: Back port r556564 | gerald | 2020-11-29 from emulators/wine-devel: Wine is now able to use mingw-w64 to build components. When mingw-w64 is installed on FreeBSD, users might inadvertedly use that when we have not set up things properly yet (and it probably should be an option to choose, at least initially). For example, mingw-w64 produces .dll files instead of the current .dll.so files, breaking pkg-plist. So for now explicitly disable the use of mingw-w64. In a next step, once mingw-w64 is available, we probably should make this an option. PR: 237213 Reported by: Damjan Jovanovic <damjan.jov@gmail.com> MFH: 2020Q4 (blanket: build issue) Changes: head/emulators/wine/Makefile
I would be much better to throw WIP patches at https://reviews.freebsd.org. (In reply to Damjan Jovanovic from comment #24) I had to do the following adjustments to compile gcc: @@ -32,7 +32,7 @@ BUILD_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils RUN_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils .else -BUILD_RUN_DEPS= ${FLAVOR:C/_/-/g}-as:devel/binutils@${FLAVOR} \ +BUILD_RUN_DEPS= ${TARGETARCH}-as:devel/binutils@${FLAVOR} \ ${LOCALBASE}/${TARGETARCH}/mingw/include/windows.h:devel/mingw-w64-headers@${FLAVOR:S/_w64_mingw32//} \ ${LOCALBASE}/${TARGETARCH}/mingw/lib/libkernel32.a:devel/mingw-w64-crt@${FLAVOR:S/_w64_mingw32//} BUILD_DEPENDS= ${BUILD_RUN_DEPS} \ @@ -54,8 +54,7 @@ GCC_VERSION= ${PORTVERSION} SUFFIX= ${PORTVERSION:C/([0-9]+).*/\1/} .if ${FLAVOR} != native -TARGETARCHAMD64=${FLAVOR:S/amd64/x86_64/} -TARGETARCH= ${TARGETARCHAMD64:C/_/-/g} +TARGETARCH= ${FLAVOR:C/_/-/g:S/amd64/x86_64/} .endif SSP_UNSAFE= yes CFLAGS:= ${CFLAGS:N-mretpoline} @@ -202,7 +201,7 @@ ${RLN} ${STAGEDIR}${INSTALL_BASE}/bin/${FLAVOR:C/_/-/g}-$F${SUFFIX} \ ${STAGEDIR}${PREFIX}/bin/${FLAVOR:C/_/-/g}-$F${SUFFIX} .endfor - ${RLN} ${STAGEDIR}${INSTALL_BASE}/bin/${FLAVOR:C/_/-/g}-gcc-${PORTVERSION} \ + ${RLN} ${STAGEDIR}${INSTALL_BASE}/bin/*-gcc-${PORTVERSION} \ ${STAGEDIR}${PREFIX}/bin/${FLAVOR:C/_/-/g}-gcc-${PORTVERSION} cd ${STAGEDIR}${PREFIX} ; if [ -d ${TARGEARCH}/bin ]; then \ ${FIND} ${TARGETARCH}/bin -type f -o -type l >>${WRKDIR}/PLIST.lib ;\ Different prefixes for gcc and binutils (amd64-w64-mingw32- and x86_64-w64-mingw32 respectively) seems to confuse Wine's build scripts, so something should be done about that as well.
(In reply to Alex S from comment #26) * It
Is this becoming obsolete as/if https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257533 lands, that uses clang cross-compilation instead?
(In reply to Gerald Pfeifer from comment #28) mingw-w64 is a legitimate port even without Wine, with other possible users including LibreOffice, wxWidgets, etc.
Created attachment 240433 [details] Updated GCC MinGW toolchain to 10.0.0 + GCC-12 Hello, I started to update the GCC patch from Damjan Jovanovic (with patches from Alex S) to MinGW-w64-10.0.0 and GCC-12. I am as far as finishing the pkg-plist for lang/gcc12, as well as a couple of fixes/clean-ups in the Makefile. Sorry I am not able to complete the update as of now, tho, I thought it best to upload my efforts thus far so they do not get lost. I did not get around to the LLVM MinGW toolchain yet :-(
Created attachment 241201 [details] WIP MinGW-w64-10.x GCC-12 The native GCC-12 build passes poudriere-testport, however, there is still some pkg-plist work for the MinGW-w64 Flavors. The Info pages for the MinGW-w64 Flavors require a post-install target to move the generated pages around, because the Ports framework (${PORTS}/Mk/bsd.port.mk) is not aware of the MinGW-w64 prefix. I am not able to get the MinGW-w64 to build with gomp or gcov at the moment.
To enable libgomp in the MinGW GCC-12 variations, MinGW C runtime and headers ports must be configured with "--with-libraries=winpthreads", however, passing this via the ports Makefile results in the configure process reporting "configure: WARNING: unrecognized options: --with-libraries", yet passing this directly to the port in ${WRKSRC} works as expected.
I am incorrect in comment #32, I think I need to create a new port from the MinGW distribution, mingw-w64-libraries, this will contain winpthreads.
Created attachment 241949 [details] WIP MinGW-w64-11.x GCC-12 This patch provides a working MinGW-w64 tool chain, however, there is some plist work do be done with symlinks so Wine-8.x finds the MinGW-w64 C compiler. The patch has only been build tested on an amd64 host. I am testing the tool chain with some patches to the Wine port.
There are depends that still need to be cleaned up too.
The 11.0.1 tarbar has been uploaded. I am slowly working on updating the current GCC patch to 11.0.1. I never finished testing the patch with Wine. I also found review D16457 which has started the dialogue on multilib support. Multilib looks like the future, and will require less, or cleaner code in the Port Makefile. I am going to look at converting the current patch to multilib too.
Oh, I am also making use of more Flavor Helpers.
Whoops, I meant review D16830.