wine-*: Don't use libpcap

[Gcenx]

With this enabled most of the MacPorts buildbots are failing so disable pcap, this didn't happen when building locally on macOS Mojave +universal nor has it happened on macOS Sonoma

@kencu weirdly the buildbots are failing due to libpcap, no clue why when this works just fine locally, I have no idea why it's the case with the buildbots when we both managed to build wine locally without issue on multiple macOS versions.

Description

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 14.7.2 23H311 x86_64
Xcode 16.2 16C5032a

Verification

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[kencu]

I saw that it has to with the fact that bison can’t build universal.

There is an issue sometimes where build tools that are already installed single-arch are considered fine, but if not installed then they are requested as universal, which may not be fine.

Solution is to eith fix the universal build, or mark them as not having a universal variant.

[kencu]

well bison +universal built fine for me on 10.13:

$ port -v installed | grep active
  bison @3.8.2_2+universal (active) requested_variants='+universal' platform='darwin 17' archs='i386 x86_64' date='2025-01-20T16:34:24-0800'

let me try 10.12

[kencu]

10.12 works fine for me too.

$ port -v installed bison
The following ports are currently installed:
  bison @3.8.2_2+universal requested_variants='+universal' platform='darwin 16' archs='i386 x86_64' date='2025-01-21T08:29:53-0800'
VMdarwi12Sierra:~$ port -v installed libpcap
The following ports are currently installed:
  libpcap @1.10.5_0+universal requested_variants='+universal' platform='darwin 16' archs='i386 x86_64' date='2025-01-21T13:57:39-0800'

now to figure out how to tell the buildbot it's OK to build bison +universal again...

[kencu]

Yes -- I also saw buildbot logs indicating libpcap +universal could not be installed because bison +universal could not be built.

@jmroot has reverted this, so maybe something has been sorted out to fix this issue.

Sometimes the buildbot logs can be a bit cryptical to sort through, and there are a lot of different systems and different builds to look through.

[jmroot]

The 10.14 and 10.15 SDKs don't support universal building, so normally no port has a universal variant on those OS versions.

Speaking of 10.14, both wine Portfiles do this:

platforms                   {darwin > 15 != 18}

But this excludes only version 18 exactly. It should almost certainly be this:

platforms                   {darwin > 15 != 18.*}

[jmroot]

@jmroot has reverted this, so maybe something has been sorted out to fix this issue.

Hopefully; waiting for the new builds to see. Builds still failed with this change to the ports, on libtapi this time.

[Gcenx]

I’d made this change going off the builtbot logs from newer versions of macOS not older versions that supported +universal where it still failed due to pcap.

[jmroot]

I see, it was configure failing to detect libpcap on macOS 12 for example. What's really needed is the config.log.

[jmroot]

Never mind, found the problem. Line 239 of wine-devel and line 205 of wine-stable:

    depends_lib                 path:lib/libMoltenVK.dylib:MoltenVK-latest

That's overwriting all the previously added dependencies. I assume it should be appending?

[Gcenx]

Yes it should have been appending, let me open another PR fixing that and the platforms line.

Any easy way to avoid builddeps being forced +universal?

[jmroot]

Any easy way to avoid builddeps being forced +universal?

If you're sure they don't need to match the archs of the port being built, you can use depends_skip_archcheck.

[Gcenx]

I’m sure they don’t need to be +universal but that could also cause other problems I’m sure so probably better to avoid that

I’ve opened a draft PR to fix the two issues you’ve mentioned here #27523

[kencu]

depends_skip_archcheck does nothing useful though if the port is not already installed.

The +universal gets passed up the chain anyway.

The only solid fix is to declare the build tool port to have no universal variant, like I did with cmake-bootstrap.

[kencu]

A comprehensive fix for the needless +universal build tool dep issue might be for any port that is “no-arch” or “sets installs_libs no” to ignore a passed-along +universal variant, and also not pass +universal up the chain to it’s deps.

Maybe that might work.

[jmroot]

depends_skip_archcheck does nothing useful though if the port is not already installed.

The +universal gets passed up the chain anyway.

Only if you ask for +universal, not if it's a default variant or added to a dep to make the archs match.