[MacPorts] #63635: libgcrypt +universal Failed to destroot: libgcrypt.pc differs in .../destroot-arm64/... and .../destroot-ppc-intel/... and cannot be merged

[MacPorts]

#63635: libgcrypt +universal Failed to destroot: libgcrypt.pc differs in
.../destroot-arm64/... and .../destroot-ppc-intel/... and cannot be merged
---------------------------+--------------------
  Reporter:  ShadSterling  |      Owner:  (none)
      Type:  defect        |     Status:  new
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.7.1
Resolution:                |   Keywords:
      Port:  libgcrypt     |
---------------------------+--------------------

Comment (by ryandesign):

 Replying to [comment:9 ShadSterling]:
 > As quoted in comment:5, the host line includes the architecture, so
 naturally differs between architectures.

 Right, which is why it has no business being in a pkg-config .pc file
 which is supposed to be an architecture-independent file. Placing such
 information in a pkg-config file demonstrates an unawareness of the
 existence of systems that include support for multiple architectures
 within the same file, such as macOS; this is not entirely surprising since
 much of the software in MacPorts is developed by people who have never
 used Macs.

 > That didn't immediately read as a bug, but looking up pkg-config nothing
 mentions the host line, so maybe that's nonstandard?  Seems potentially
 useful for cross-compiling; maybe muniversal should remove it?

 pkg-config includes the ability to put arbitrary data into .pc files; the
 host line comes under that heading. We don't know in what ways, if at all,
 each program might use the `host` information in the pkg-config file. My
 expectation is that the developers put it in there on the assumption that
 it would be useful to someone but that they don't use it at all, but I
 don't know if that's true.

 Instead of having the muniversal portgroup indiscriminately remove that
 nonstandard line at the risk of breaking some software that relies on it
 being there, it would be a better idea to educate each software developer
 about how adding architecture-specific information to pkg-config files is
 contrary to the purpose of pkg-config files and have them fix their code
 to not do that. That way everyone benefits, not just MacPorts users. (We
 can also patch the problem in each affected Portfile until the upstream
 software is fixed.)

-- 
Ticket URL: <https://trac.macports.org/ticket/63635#comment:10>
MacPorts <https://www.macports.org/>
Ports system for macOS