adblock2privoxy, privoxy, sf-pwgen, libgcrypt dependency issue on arm

[essandess (Steve Smith)]

There's some arm dependency issue that's preventing adblock2privoxy from being installed on M1 boxes.

The install appears to be demanding that +universal builds in its dependencies be installed, and it goes off trying to do that, and failing.

The dependent ports install fine, as shown below, but not in the context of sudo port install adblock2privoxy. I'm not sure which port to blame, or whether port itself is at fault in sorting this out:

sudo port clean --work --logs adblock2privoxy privoxy sf-pwgen libgcrypt
--->  Cleaning adblock2privoxy
--->  Cleaning privoxy
--->  Cleaning sf-pwgen
--->  Cleaning libgcrypt

port installed adblock2privoxy privoxy sf-pwgen libgcrypt
The following ports are currently installed:
  libgcrypt @1.9.4_0 (active)
  privoxy @3.0.32_6+https_inspection (active)
  sf-pwgen @1.5_0 (active)

sudo port install adblock2privoxy
--->  Computing dependencies for libgcrypt
--->  Fetching archive for libgcrypt
--->  Attempting to fetch libgcrypt-1.9.4_0+universal.darwin_21.arm64-x86_64.tbz2 from https://packages.macports.org/libgcrypt
--->  Attempting to fetch libgcrypt-1.9.4_0+universal.darwin_21.arm64-x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/libgcrypt
--->  Attempting to fetch libgcrypt-1.9.4_0+universal.darwin_21.arm64-x86_64.tbz2 from https://mse.uk.packages.macports.org/libgcrypt
--->  Fetching distfiles for libgcrypt
--->  Verifying checksums for libgcrypt
--->  Extracting libgcrypt
--->  Applying patches to libgcrypt
--->  Configuring libgcrypt
Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:
  fn: found in libgcrypt-1.9.4-arm64/config.log, libgcrypt-1.9.4-x86_64/config.log
--->  Building libgcrypt
--->  Staging libgcrypt into destroot                    
Error: Failed to destroot libgcrypt: libgcrypt.pc differs in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libgcrypt/libgcrypt/work/destroot-arm64//opt/local/lib/pkgconfig and /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libgcrypt/libgcrypt/work/destroot-ppc-intel//opt/local/lib/pkgconfig and cannot be merged
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libgcrypt/libgcrypt/main.log for details.
Error: Unable to execute port: upgrade privoxy failed

The install worked about a month ago; I recently updated to macOS 12, and there's also the recent change to haskell_stack, ​https://github.com/macports/macports-ports/pull/11897/commits/9a215f65a650bda42b20c368f85dc9ead69813b0, or there could be some other issue.

macOS 12.0.1 21A559 arm64
Xcode 13.1 13A1030d

[jmroot (Joshua Root)]

The libgcrypt +universal failure is #63635.

Ports using the haskell_stack portgroup are always built as x86_64, and it's normal for dependencies to be installed as +universal when you build for x86_64 on a system where build_arch is something else.

[essandess (Steve Smith)]

Replying to jmroot:

The libgcrypt +universal failure is #63635.

Ports using the haskell_stack portgroup are always built as x86_64, and it's normal for dependencies to be installed as +universal when you build for x86_64 on a system where build_arch is something else.

Thanks.

Does this mean we have to create +universal variants for all build_arch x86_64 ports we want to run on an M1? That sounds … like lots of work.

Right now they just download and work on the M1.

What’s the fix to this issue? I believe that adblock2privoxy is also trying to install privoxy +universal, which doesn’t exist.

[ryandesign (Ryan Carsten Schmidt)]

All ports should offer universal variants if possible; this ticket shows one reason why that's a good idea.

[essandess (Steve Smith)]

The solution to this and related issues on an M1 box is:

sudo port install adblock2privoxy supported_archs=

[essandess (Steve Smith)]

Replying to ryandesign:

All ports should offer universal variants if possible; this ticket shows one reason why that's a good idea.

I do not believe that a +universal variant applies in this case, and that the exhibited MacPorts behavior is a bug.

There is no universal build here—all the builds are x86_64. These x86_64 builds also run on arm64 architecture machines. Therefore, port should just install the x86_64 binaries on M1 boxes. The behavior of adding the +universal dependency is unnecessary, not necessarily correct, and causes multiple issues.

[essandess (Steve Smith)]

Related thread: ​https://lists.macports.org/pipermail/macports-dev/2021-August/043663.html

[essandess (Steve Smith)]

This is a recurring issue:

$ sudo port -puNc upgrade adblock2privoxy
--->  Computing dependencies for adblock2privoxy
Error: Cannot install adblock2privoxy for the arch 'x86_64' because
Error: its dependency sf-pwgen does not build for the required arch by default
Error: and does not have a universal variant.
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.

$ arch
arm64

$ port installed sf-pwgen
The following ports are currently installed:
  sf-pwgen @1.5_0 (active)

$ sf-pwgen
quiz494{snit
sprig15,stow
Cooke67"FNMA
clues35-RSVP
imbue1(Incas

[essandess (Steve Smith)]

I added supported_archs arm64 x86_64 to sf-pwgen in ​https://github.com/macports/macports-ports/pull/13356, but Haskell builds are still throwing this error:

sudo port destroot adblock2privoxy
Error: Cannot install adblock2privoxy for the arch 'x86_64' because
Error: its dependency sf-pwgen is only installed for the arch 'arm64'
Error: and does not have a universal variant.
Error: Unable to execute port: architecture mismatch

[jmroot (Joshua Root)]

In b1e5f733d4076a9ae947ccfc71dd91856ebf39fb/macports-ports (master):

sf-pwgen: various fixes

• Set correct license.
• Set installs_libs no; only an executable is installed.
• Remove incorrect supported_archs line that was added in 85e0ec8, apparently with the hope of preventing architecture mismatch errors (in fact it just prevented building for i386, because all archs are considered supported if there's no explicit supported_archs).

See: #63944

[essandess (Steve Smith)]

Thank you! That resolves this issue.