[MacPorts] #66627: ghostscript fails to configure with universal variant

MacPorts noreply at macports.org
Thu Jan 5 20:42:00 UTC 2023


#66627: ghostscript fails to configure with universal variant
----------------------------+--------------------
  Reporter:  MichaelGDev48  |      Owner:  kencu
      Type:  defect         |     Status:  closed
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:  2.8.99
Resolution:  fixed          |   Keywords:
      Port:  ghostscript    |
----------------------------+--------------------

Comment (by Gcenx):

 Replying to [comment:11 kencu]:
 > Dean, the reason that ghostscript fails cross compilation is that is is
 purposefully written into Ghostscript's configure script to do so.

 Yes that’s very common due to how Linux gets setup with the GNU toolchain.


 > It has nothing to do with gcc or meson or setting of targets. If the
 build != host, the configure will not use pkgconfig unless instructed how
 to do so. I do get that, although it seems most software does not have
 that written into it. The Ghostscript devs must have been stung a few
 times to add that.

 Guess I’m not explaining myself well enough here?

 The reason for these kind of checks is due to how a standard GNU toolchain
 is setup as explained via the llvm/clang documentation and the reason when
 meson for example stopped allowing darwin targets from using host tools as
 on Linux that isn’t usually possible.

 For meson when trying to compile to/from ChromeOS to another Linux
 platform there were issues so now if both build & host don’t match it
 assumes your cross-compiling so requires the expected prefixed tools.

 > As a general principle, telling an M1 Mac it is an Intel system to fix a
 build is less-than-ideal quickie fix, last resort only.

 That’s not really what your doing as you’ll notice configure will still
 detect the system as arm64 your just telling configure that it can use the
 host utility’s instead of needing prefixed ones.

 > The fix I pushed here appears proper and accurate. There may have been
 another fix, something like setting "BUILD_PKGCONFIG" but that was
 unnecessary in our MacPorts environment.

 This would also be the case for other configure based projects as long as
 all the env get set it should compile without issue, I’m not saying this
 is wrong it can just become much more work for some projects.

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


More information about the macports-tickets mailing list