mingw-w64 fails if called via another port that’s using the +universal variant

[Gcenx]

I’m currently working on updating wine-devel and mingw-w64 is now part of the build dependancies, the issue happens if mingw-w64 isn’t already installed and the following is used for example using

port install wine-devel +universal

I get the following errors

--->  Computing dependencies for wine-devel...........
Error: Cannot install i686-w64-mingw32-crt for the archs 'i386 x86_64' because
Error: its dependency i686-w64-mingw32-gcc-bootstrap does not build for the required archs by default
Error: and does not have a universal variant.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port wine-devel failed

The updated wine-devel can be found here ​https://github.com/Gcenx/macports-wine-devel

If this is intended behavior how could I work around this issue within the Portfile?

[jmroot (Joshua Root)]

If the architectures don't need to match then you can set depends_skip_archcheck i686-w64-mingw32-gcc-bootstrap in the port that has the dependency.

[Gcenx]

Replying to jmroot:

If the architectures don't need to match then you can set depends_skip_archcheck i686-w64-mingw32-gcc-bootstrap in the port that has the dependency.

I’m assuming I could do depends_skip_archcheck mingw-w64? as I do need all components of mingw-w64 for compiling wine as universal anyway.

[mojca (Mojca Miklavec)]

I didn't intentionally make any of the mingw ports non-universal, that is: I'm not yet aware of any reason why the port would not build as universal until I try it and fail.

Also, there are a number of things that are not entirely clear to me. To start with, mingw-w64 is declared as being noarch, so it's not clear to me why MacPorts is complaining about universal in the first place. Also, mingw-w64 is nothing but a meta-port. To me it sounds better to declare a dependency on the actual compiler if it is actually needed. (Do you need both the comper producing 32-bit and 64-bit windows binaries?)

Second, I can of course try to make the compiler build as universal, but it's not clear to my why that would be needed / how that could be useful. I'm not even sure in what way mingw is used as a wine dependency. For all I know wine worked fine long before I even finished the ports.

I certainly need more data if I'm about to do anything about this.

[Gcenx]

Wine versions prior to Wine-4.15 didn’t make use of mingw-w64 so it would have been a none issue. Now wine is using mingw-w64 to build multiple dll/exe file as native Windows binaries instead of fake dll files that linked to .so files that mapped to the native dylibs on macOS.

I’m aware mingw-w64 is the meta package I’m calling it directly due to needing all of it for compiling wine as universal.

wine uses i686 components of mingw for 32Bit builds. wine64 uses x86_64 components of mingw for 64Bit builds.

I don’t believe i686 would need to be compiled as universal since it’s a 32Bit compiler and x86_64 is 64Bit, I’m mostly confused why macports seems to think it can’t install components of mingw-w64 due to my usage of +universal that’s required to build the full wine/wine64 port.

As i also mentioned if I can add something into the wine-devel Portfile to not pass the +universal flag and works I take that, as if I installed mingw-w64 before hand my Portfile works just fine

[mojca (Mojca Miklavec)]

Please note the distinction between having 32-bit mac binary / 64-bit mac binary vs. the compiler producing either 32-bit or 64-bit executables.

I understand the need for i686-w64-mingw32-gcc to produce 32-bit binaries for Windows, but I don't understand why either i686-w64-mingw32-gcc or x86_64-w64-mingw32-gcc would need to be a 32-bit mac binary itself.

Unless the wine developers recently solved some of the issues, wine itself may still need to be built as universal though.

[Gcenx]

Sorry for the confusion.

I don’t believe any part component of mingw-w64 would need to be compiled as a 32Bit macOS binary all could be 64Bit. (I’ve cross-compiled wine for macOS on a pure 64Bit version of Debian stretch without issue.)

Wine won’t be “fixed” as you put it until CrossOver 19 and that will be requiring a custom patch version of llvm/clang or compiling the custom llvm/clang source as a toolchain to be used by XCode, it might also take sometime for those changes to make there way into upstream wine.

[kencu (Ken)]

Doesn't it seem that the ming-* Portfiles themselves should have something in them to resolve this automatically, for any ports that are asked to build +universal, but then call a ming* port as a dependency?

It seems - cumbersome - that any port calling on a ming* port has to know about these internal ming things.

Is installs_libs no or similar for this purpose?

[jmroot (Joshua Root)]

Replying to mojca:

I didn't intentionally make any of the mingw ports non-universal, that is: I'm not yet aware of any reason why the port would not build as universal until I try it and fail.

The crossgcc.setup proc sets universal_variant no.

Also, there are a number of things that are not entirely clear to me. To start with, mingw-w64 is declared as being noarch, so it's not clear to me why MacPorts is complaining about universal in the first place.

MacPorts is complaining in the context of i686-w64-mingw32-crt, which does have a universal variant, and depends on i686-w64-mingw32-gcc-bootstrap, which does not have a universal variant.

[Gcenx]

I'm not sure if this even matters anymore as my updated wine-* Portfiles don't require calling +universal anymore, plus the changes to the universal handling within Macports maybe this might not even be valid anymore?

[mojca (Mojca Miklavec)]

For all I know you were the only one who mentioned this issue. If it's no longer relevant to you, we can close the ticket.

I only now realized that I don't remember reading Joshua's hint about -crt potentially missing an explicit universal_variant no, but even that wouldn't really be any closer to the real solution.

Let me know if you think that this ticket should be close (even if it remains open, I'm not really sure what I can do about it).

[Gcenx]

Yeah I don’t really see anyone directly calling mingw-w64 +universal this “should” really only apply to anyone who’s forcing 10.13 target/SDK on Mojave. So it should be fine to close it.