wine{,-{devel,crossover}}: new +universal woes

[Ionic (Mihai Moldovan)]

Upgrading an already installed wine-devel port (but I figure it's the same for the other ports as well, since the change was carried out in sync), the +universal flag is not added by default.

If this upgrade succeeded, people would be left with a 64 bit wine variant only, which breaks the old behavior heavily. No, people wouldn't be left with a 64 bit wine variant only, since -universal seems to mean "i386 wine only", contrary to the normal +universal handling, see below. Hence the behavior would be backwards-compatible, but still weird.

Luckily enough, at least on my 10.9 machine, it's not upgrading successfully anyway.

It looks like since supported_archs now contains x86_64 and i386, non-universal builds will be built with a -m32 flag, but also the -arch x86_64 flag, which leads to... interesting effects, apparently.

Also, I'm not sure that the dependencies are checked for +universal any longer with this approach.

Maybe we should just delete x86_64 from supported_archs if the universal flag is not enabled?

Aside from the build failure, I think we also have a logical problem here. +universal normally refers to building software for non-primary architectures as well (example: base/primary arch = x86_64, universal arches = base/primary_arch(x86_64) i386), but this port now seems to reverse this logic, if I get what you intended correctly. The default build without +universal is supposed to build for i386 only (even if it's a non-primary arch), while +universal adds the primary arch x86_64. Shouldn't we reverse this again to make stuff... consistent?

[Ionic (Mihai Moldovan)]

wine-devel main.log

[Ionic (Mihai Moldovan)]

wine-devel config.log

[Ionic (Mihai Moldovan)]

Hm, I think the intention was indeed a different one: build a primary-arch wine by default and the non-primary arch version only with +universal.

I'm not sure this is a good idea, since it'll leave most users with a 64bit wine variant by default (short of users on ancient systems that defaulted to i386), which will be problematic for old 32bit wine environments. I don't think these can be upgraded to 64bit wineprefixes directly. AFAIK downgrading is also not supported. So in such a case, the prefix will just fail to work.

We could add --with-win64 to the non-universal configure.args if the base arch is x86_64 to fix the build failure, I guess, which should make wine building and installing a 64bit version, instead of defaulting to its 32bit version.

[raimue (Rainer Müller)]

On x86_64, wine sets default_variants +universal, so this variant should automatically be added on upgrades.

I do not think purse 64-bit builds of wine that are useful. Users either want only win32 (-universal) or win32 and win64 (+universal). At least this was the intention how it should work.

Ending up with both -m32 and -arch x86_64 looks indeed like a problem. Probably caused by muninversal that might add -arch flags although we are not even building +universal. Removing x86_64 from supported_archs sounds like a good workaround. I cannot test this at the moment, though.

[Ionic (Mihai Moldovan)]

ports state file

[ryandesign (Ryan Carsten Schmidt)]

Replying to raimue:

Ending up with both -m32 and -arch x86_64 looks indeed like a problem. Probably caused by muninversal that might add -arch flags although we are not even building +universal.

Set merger_arch_flag no?

Removing x86_64 from supported_archs sounds like a good workaround. I cannot test this at the moment, though.

This breaks the port:

Error: wine cannot be installed for the configured universal_archs 'x86_64 i386' because it only supports the arch(s) 'i386'.

[Ionic (Mihai Moldovan)]

On x86_64, wine sets default_variants +universal, so this variant should automatically be added on upgrades.

If I interpret the state file correctly, +universal seems to not have been added.

Also, from the build log, I see that it's using the wine-3.4 worksrcdir instead of an arch-specific one, so that also hints at +universal not being enabled.

I do not think purse 64-bit builds of wine that are useful. Users either want only win32 (-universal) or win32 and win64 (+universal). At least this was the intention how it should work.

It looks like currently -universal defaults to a broken wine32 build, since it builds with -arch x86_64 but also -m32 (which comes from wine itself for its win32 variant).

Removing x86_64 from supported_archs sounds like a good workaround. I cannot test this at the moment, though.

This breaks the port:

Error: wine cannot be installed for the configured universal_archs 'x86_64 i386' because it only supports the arch(s) 'i386'.

Hum, do we check universal_archs against supported_archs even if not building +universal?

Does this also occur with

if {![variant_isset universal] && ${build_arch} eq "x86_64"} {
    supported_archs i386
}

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

Replying to raimue:

Ending up with both -m32 and -arch x86_64 looks indeed like a problem. Probably caused by muninversal that might add -arch flags although we are not even building +universal.

Set merger_arch_flag no?

Sorry, I missed the original statement from the ticket's description:

non-universal builds will be built with a -m32 flag, but also the -arch x86_64 flag

The muniversal portgroup doesn't do anything for non-universal builds, so setting merger_arch_flag no wouldn't do anything to address that.

Removing x86_64 from supported_archs sounds like a good workaround. I cannot test this at the moment, though.

This breaks the port:

Error: wine cannot be installed for the configured universal_archs 'x86_64 i386' because it only supports the arch(s) 'i386'.

Sorry, I missed the original statement from the ticket's description:

delete x86_64 from supported_archs if the universal flag is not enabled

Yes, doing it only when the universal variant is not set might work.

[Ionic (Mihai Moldovan)]

The muniversal portgroup doesn't do anything for non-universal builds, so setting merger_arch_flag no wouldn't do anything to address that.

Yeah, I'm pretty sure -m32 comes from wine itself which adds it when building its win32 variant on a non-i386 platform. And -arch base_arch is just part of the usual flags we pass to builds when building a base-arch port.

Yes, doing it only when the universal variant is not set might work.

Might, but then again would leave us with the "logical dilemma" I mentioned in the report - for wine ports, the behavior of +universal would be reversed compared to all other ports. I don't feel too comfortable with that, but it's the maintainer's decision in the end.

Maybe we shouldn't use universal here at all, but rather introduce new win32 and win64 (or wine32 and wine64) variants that enable building a specific variant, irrespective of the machine's base arch. Do we actually need muniversal and merging here? Wine normally adds postfixes to its 64bit variant binaries. Libraries will need to be staged into different directories (and we should make sure to tell wine where to find those in the build process), but I don't think that muniversal is actually useful here. We don't want to actually merge thin binaries into fat binaries. We already stage stuff into different directories via the dlldir override.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Ionic:

Yes, doing it only when the universal variant is not set might work.

Might,

I am testing it now.

but then again would leave us with the "logical dilemma" I mentioned in the report - for wine ports, the behavior of +universal would be reversed compared to all other ports. I don't feel too comfortable with that, but it's the maintainer's decision in the end.

I am not terribly concerned about it. There are two valid builds of wine: 32-bit only, and 32-bit-and-64-bit. Using the universal variant for this is slightly weird, but wine itself is more than slightly weird anyway.

Maybe we shouldn't use universal here at all, but rather introduce new win32 and win64 (or wine32 and wine64) variants that enable building a specific variant, irrespective of the machine's base arch. Do we actually need muniversal and merging here? Wine normally adds postfixes to its 64bit variant binaries. Libraries will need to be staged into different directories (and we should make sure to tell wine where to find those in the build process), but I don't think that muniversal is actually useful here. We don't want to actually merge thin binaries into fat binaries. We already stage stuff into different directories via the dlldir override.

There is extensive discussion about how the 64-bit support was added to wine in the previous ticket and PR. I deliberately stayed out of the discussion because I did not want to take on the responsibility. I left it to someone else to decide what to do. And it was done, and they thought it worked.

[raimue (Rainer Müller)]

The upgrade works as expected here. I installed the old archive to test. This is with base master, but I do not think we changed anything.

$ port -q installed wine
  wine @3.0_0+x11 (active)
$ sudo port -n upgrade wine
--->  Computing dependencies for wine
--->  Fetching archive for wine
--->  Attempting to fetch wine-3.0_1+universal+x11.darwin_16.i386-x86_64.tbz2 from http://nue.de.packages.macports.org/wine
...

The merging feature of muniversal is not actually needed. muniversal is used because you need to build twice with different flags. You could do that without muniversal, but that probably means re-implementing what muniversal does.

[ryandesign (Ryan Carsten Schmidt)]

This​ seems to work for me.

[Ionic (Mihai Moldovan)]

The upgrade works as expected here. I installed the old archive to test. This is with base master, but I do not think we changed anything.

Hmm, this has been likely my fault. My variants.conf contains -universal (in order to only get +universal builds when I request them specifically).

And it was done, and they thought it worked.

I believe that it worked for +universal builds which is the default configuration. It's likely that nobody tested -universal builds.

This​ seems to work for me.

Seems to work for me as well. I'll let the build finish and then test with +universal set.

[Ionic (Mihai Moldovan)]

Also looks good for the +universal case.

[ostefano (Stefano Ortolani)]

I will open a new ticket, but I am checking here first whether this is known already. Latest wine (including -devel) built with +universal +quartz seem to freeze (component timeout) when opening winecfg (first execution). Forcefully closing it leaves dangling processes. This on High Sierra and on two different installations.

[Ionic (Mihai Moldovan)]

Latest wine (including -devel) built with +universal +quartz seem to freeze (component timeout) when opening winecfg (first execution).

The wine ports do not feature a quartz variant. It's not relevant to them. Did you also set -x11?

The x11 variant enables or disables the X11 driver, while the MacDriver (or whatever it's called nowadays) that uses Quartz is always built.

(first execution).

Did you have a wineprefix already? Sounds like no, but if yes, does WINEARCH=win32 winecfg behave differently?

It might be possible that an existing prefix was set to the X11 driver, which means that wine will not start correctly if built with -x11 now.

This said, it doesn't sound like this has anything to do with this ticket.

[ryandesign (Ryan Carsten Schmidt)]

In ee3012e97022e97da2af8fae1bb5bda1af067d56/macports-ports:

wine*: Fix non-universal build, making it 32-bit again

Closes: #56143

[ostefano (Stefano Ortolani)]

Replying to Ionic:

Latest wine (including -devel) built with +universal +quartz seem to freeze (component timeout) when opening winecfg (first execution).

The wine ports do not feature a quartz variant. It's not relevant to them. Did you also set -x11?

The x11 variant enables or disables the X11 driver, while the MacDriver (or whatever it's called nowadays) that uses Quartz is always built.

(first execution).

Did you have a wineprefix already? Sounds like no, but if yes, does WINEARCH=win32 winecfg behave differently?

It might be possible that an existing prefix was set to the X11 driver, which means that wine will not start correctly if built with -x11 now.

This said, it doesn't sound like this has anything to do with this ticket.

You are right. It affects only WINEARCH=win64. Removed the prefix, still freezes. Opening a ticket (#56166)