harfbuzz fails to configure with gcc on Sonoma: error: CoreText support requested but libcoretext not found

[barracuda156]

--->  Configuring harfbuzz
Executing:  cd "/opt/svacchanda/local/var/macports/build/_opt_svacchanda_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_harfbuzz/harfbuzz/work/harfbuzz-8.3.0" && ./configure --prefix=/opt/svacchanda/local --disable-silent-rules --without-chafa ac_cv_prog_AWK=/usr/bin/awk --with-cairo --with-freetype --with-glib --with-graphite2 --with-gobject --without-icu --with-coretext --enable-introspection 
. . .
checking for glib-2.0 >= 2.10.0 gobject-2.0  >= 2.10.0... yes
checking for atexit... yes
checking for mprotect... yes
checking for sysconf... yes
checking for getpagesize... yes
checking for mmap... yes
checking for isatty... yes
checking for newlocale... yes
checking for uselocale... yes
checking for sincosf... no
checking for unistd.h... (cached) yes
checking for sys/mman.h... yes
checking for stdbool.h... yes
checking for xlocale.h... yes
checking alignment of struct{char;}... 1
checking whether the linker accepts -Bsymbolic-functions... yes
checking for native Win32... no
checking how to run the C preprocessor... /opt/svacchanda/local/bin/gcc-mp-13 -E
checking whether /opt/svacchanda/local/bin/gcc-mp-13 is Clang... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
checking for glib-2.0 >= 2.19.1... yes
checking for gobject-2.0 glib-2.0... yes
checking for gobject-introspection... yes
checking for cairo >= 1.8.0... yes
checking for cairo_user_font_face_set_render_color_glyph_func... yes
checking for cairo-ft... yes
checking for graphite2 >= 1.2.0... yes
checking for freetype2 >= 12.0.6... yes
checking for FT_Get_Var_Blend_Coordinates... yes
checking for FT_Set_Var_Blend_Coordinates... yes
checking for FT_Done_MM_Var... yes
checking for FT_Get_Transform... yes
checking for CTFontRef... no
checking for CTRunRef... no
configure: error: CoreText support requested but libcoretext not found
Command failed:  cd "/opt/svacchanda/local/var/macports/build/_opt_svacchanda_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_harfbuzz/harfbuzz/work/harfbuzz-8.3.0" && ./configure --prefix=/opt/svacchanda/local --disable-silent-rules --without-chafa ac_cv_prog_AWK=/usr/bin/awk --with-cairo --with-freetype --with-glib --with-graphite2 --with-gobject --without-icu --with-coretext --enable-introspection 
Exit code: 1

[barracuda156]

Same failure with 8.2.2 and 8.3.0

[ryandesign (Ryan Carsten Schmidt)]

Don't use gcc on Sonoma; use clang.

[barracuda156]

Replying to ryandesign:

Don't use gcc on Sonoma; use clang.

In principle, both compilers and both C++ runtimes should work across all supported systems (leaving powerpc aside for the time-being). If they do not, something is wrong.

Of course, port maintainers may not be willing to fix non-standard combinations, which is why I did not assign ticket to anyone. Yet, it is a bug.

[ryandesign (Ryan Carsten Schmidt)]

It's not a bug for MacPorts to fix. On modern macOS, MacPorts selects a clang compiler to build this port, and that works. We don't support users picking random compilers to build their ports.

The config.log contains a zillion errors related to the system headers, starting with:

configure:22970: checking for CTFontRef
configure:22970: /opt/svacchanda/local/bin/gcc-mp-13 -c -pipe -Os -DHB_NO_PRAGMA_GCC_DIAGNOSTIC_ERROR -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -I/opt/svacchanda/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk conftest.c >&5
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Headers/ATS.h:32,
                 from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:27,
                 from conftest.c:48:
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Headers/ATSFont.h: In function 'ATSGetGeneration':
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Headers/ATSFont.h:230:24: error: expected declaration specifiers before 'ATS_UNAVAILABLE'
  230 | ATSGetGeneration(void) ATS_UNAVAILABLE;
      |                        ^~~~~~~~~~~~~~~

so either something about the way that conftest.c is using the system headers is not compatible with gcc, or (more likely in my opinion) the system headers themselves are not compatible with gcc. Harfbuzz isn't doing anything particularly exotic in its test, just #include <ApplicationServices/ApplicationServices.h>:

​https://github.com/harfbuzz/harfbuzz/blob/894a1f72ee93a1fd8dc1d9218cb3fd8f048be29a/configure.ac#L388

You can try yourself if this works with your compiler:

% cat test.c
#include <ApplicationServices/ApplicationServices.h>
int main(void) {}
% clang -o test test.c
% gcc-mp-12 -o test test.c
[a zillion errors]

So the system headers are not compatible with gcc, and if you want that to change, you'd have to file a bug report with Apple and/or the developers of gcc.

A similar error was ​reported to wxwidgets when trying to use gcc to build it on macOS, and their response was don't do that; use clang.

This would not be the first time macOS system headers have not been compatible with gcc. Here is ​a previous instance.