[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