ghostscript fails to configure with universal variant

[MichaelGDev48 (Michael G)]

Upon trying to install ghostscript +universal it errors on configure stage Might be an issue with being outdated as the port hasnt been updated in 6 months I'm on macOS Ventura, on a MacBook Air M1

[MichaelGDev48 (Michael G)]

main log

[kencu (Ken)]

having trouble finding ft2build.h:

3590	:info:configure checking for local freetype library source... no
3591	:info:configure checking for ft2build.h... no
3592	:info:configure configure: error: No usable Freetype source or library found

although it lists a dep on freetype:

Library Dependencies: fontconfig, freetype...

and the header is there:

% port content freetype | grep ft2build.h
  /opt/local/include/freetype2/ft2build.h

... let's see...

[MichaelGDev48 (Michael G)]

yep and if i do port installed freetype this outputs:

The following ports are currently installed:
  freetype @2.12.1_0
  freetype @2.12.1_0+universal (active)

[kencu (Ken)]

Yeah, me too -- and I already have the non-universal Ghostscript installed...

% port -v installed ghostscript
The following ports are currently installed:
  ghostscript @9.56.1_1+x11 (active) requested_variants='' platform='darwin 22' archs='arm64' date='2022-12-27T13:42:47-0800'

and it finds freetype just fine:

checking for local freetype library source... no
checking for system freetype2 >= 2.4.2 with pkg-config... yes

but the universal version does not... a bit strange...

I added the path the include file, and it got a little further:

configure:8926: checking for system freetype2 library >= 2.4.2
configure:8951: /usr/bin/clang -c -pipe -Os -arch x86_64 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk -DHAVE_RESTRICT=1 -DUSE_LIBICONV_GNU -DUSE_LIBPAPER -isystem/opt/local/include -I/opt/local/include/freetype2 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk conftest.c >&5
conftest.c:59:20: error: use of undeclared identifier 'FAIL'
                   FAIL
                   ^

but seems to want a newer version of freetype.

Something odd is going on here.

[ryandesign (Ryan Carsten Schmidt)]

I note that you have MACOSX_DEPLOYMENT_TARGET set to 11.0 which is unusual on Ventura.

[kencu (Ken)]

my best guess for this right now is that autotools is not using pkg-config’s info for the cross build because it is cross-compiling.

see ​https://www.freedesktop.org/wiki/Software/pkg-config/CrossCompileProposal/

we might set the build macine to be an x86_64 system on arm64 during the cross to get past this, if there is not a proper fix.

I think muniversal 1.1 has an option to do this.

[kencu (Ken)]

I didn't use muniversal 1.1 (as yet) but setting the build machine like this as a quick hack in the Portfile on the M1 system did work:

if {${universal_possible} && [variant_isset universal]} {
        set merger_configure_args(x86_64)     --build=x86_64-apple-darwin22.2.0
}

% port -v installed ghostscript
The following ports are currently installed:
  ghostscript @9.56.1_1+universal+x11 (active) requested_variants='+universal' platform='darwin 22' archs='arm64 x86_64' date='2023-01-05T08:06:40-0800'

as written this is not a generally correct fix just yet -- and it's not really the right fix either, TBH, as the cross-build should be made to work...

[kencu (Ken)]

This bit in Ghostscript's configure.ac is interesting, and likely relevant to the failure I think:

# If the caller has gives a specific pkg-config to use, then
# use it, and skip the tests.
if test x"$PKGCONFIG" != x"" ; then
    AC_MSG_NOTICE([Using $PKGCONFIG])
else
# this is an unpleasant hack
# but if we are cross compiling, and there isn't a matching
# pkconfig for the --host setting, then don't use the 'local'
# pkconfig at all
  AC_PATH_TOOL(PKGCONFIG, pkg-config)
  if test x"$host" != x"$build" ; then
    dnl pkg-config is used for several tests now...
    AC_PATH_PROG(BUILD_PKGCONFIG, pkg-config)
    if test x"$BUILD_PKGCONFIG" = x"$PKGCONFIG" ; then
      PKGCONFIG=
    fi
  fi
fi

[kencu (Ken)]

and yes indeedy, this fixes things in a proper way:

# tell ghostscript it's OK to use the system pkg-config even when cross-compiling
configure.env-append PKGCONFIG=${prefix}/bin/pkg-config

[kencu (Ken)]

In 88d0ef833e32a8adee8ea4847ee01f8e3d5e514e/macports-ports (master):

ghostscript: add PKGCONFIG to environment

setting this env var tells ghostscript it's OK to use
the system pkg-config even when cross-compiling

closes: #66627

[Gcenx]

As I’ve explained before the reason configure and other build systems (like meson) work in this manner is GCC see ​https://clang.llvm.org/docs/CrossCompilation.html.

Weirdly having trouble finding the -target documentation so won’t go into that.

[kencu (Ken)]

Dean, the reason that ghostscript fails cross compilation is that is is purposefully written into Ghostscript's configure script to do so.

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.

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.

The fix I pushed here is proper and accurate.

[Gcenx]

Replying to 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.

[kencu (Ken)]

yes, I won’t be using the “tell an M1 it’s Intel”:approach unless it’s last resort, exactly.

You and I have been doing this stuff together some years now… I finally got a ripping fast M1 so fixed about 60 broken builds since then… looking forward to doing the rest with you in the next while.

Glad MP has attracted such interested people!