harfbuzz 5.2 won't compile -- syntax error from mmintrin.h?

[michael-j-oconnor]

I'm not sure what's going wrong, but this is where it seems to break. Log attached.

:info:build /usr/bin/clang -E -I/opt/local/include -DHB_NO_SINGLE_HEADER_ERROR -DHAVE_GOBJECT -DHB_EXTERN= -U__BLOCKS__ -I. -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_harfbuzz/harfbuzz/work/harfbuzz-5.2.0/src -o g-ir-cpp-37veyc8k.i -C -pthread /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_harfbuzz/harfbuzz/work/harfbuzz-5.2.0/src/g-ir-cpp-37veyc8k.c
:info:build /Library/Developer/CommandLineTools/usr/lib/clang/10.0.0/include/mmintrin.h:1298: syntax error, unexpected '{' in '    return (__m64){ 0LL };' at '{'
:info:build /Library/Developer/CommandLineTools/usr/lib/clang/10.0.0/include/xmmintrin.h:228: syntax error, unexpected '{' in '  return (__m128) { __c[0], __a[1], __a[2], __a[3] };' at '{'

[michael-j-oconnor]

full logs of harfbuzz compile failure

[michael-j-oconnor]

I still see the same problem with MacPorts 2.8.0, FWIW. (I doubted it'd make a different, but seemed to be worth a shot.) I don't _think_ I'm doing anything horribly unusual here. Everything else builds, apart from harfbuzz and what depends on it.

[michael-j-oconnor]

I see the same issue with harfbuzz 5.3.1. See attached logs.

The big difference between what MacPorts buildbots test with is Xcode 9.4 vs Xcode 10.1 (latest for 10.13.6). Any reason not to use the latest/lastest Xcode?

[michael-j-oconnor]

similar failure in compiling with harfbuzz 5.3.1

[ryandesign (Ryan Carsten Schmidt)]

Replying to michael-j-oconnor:

I see the same issue with harfbuzz 5.3.1. See attached logs.

Sorry, I don't know why this fails for you. We have successful builds of this port on all OS versions on our buildbot system.

The big difference between what MacPorts buildbots test with is Xcode 9.4 vs Xcode 10.1 (latest for 10.13.6). Any reason not to use the latest/lastest Xcode?

Yes, there is a reason: I generally try to keep the buildbot workers running the latest version of Xcode that contains the SDK version that matches the OS version. Xcode 9.4 is the last Xcode version that has the 10.13 SDK so that's why I use that on the 10.13 buildbot worker.

Since it works on the buildbot, you might consider downgrading your Xcode and command line tools to 9.4.

Also, we have binaries of harfbuzz and most other ports available. MacPorts should try to retrieve them by default. Your log shows that it did not try. If that's due to your MacPorts configuration, you might consider reconfiguring so that you can benefit from our binaries and not have to compile everything yourself.

[michael-j-oconnor]

Yeah, I can use the binaries for harfbuzz. Go ahead and close. A decade or so ago, some bug caused to me to set "buildfromsource always". I've never had significant issue until now. I'm surprised that MacPorts buildbots don't use the latest for their OS, which is what users are told to run.

[blair (Blair Zajac)]

I don't think this ticket should be closed as there is a legitmate build failure.

The mmintrin.h isn't specific to mac OS as that header is also found on linux, so I'm not certain why it should be tied to the 10.13 SDK.

[ryandesign (Ryan Carsten Schmidt)]

Replying to michael-j-oconnor:

I'm surprised that MacPorts buildbots don't use the latest for their OS, which is what users are told to run.

It is the tradeoff that we have so far chosen to use.

Using the latest Xcode that is compatible with a macOS version will cause some ports to fail to build because those port require an SDK that matches the OS version, and the latest Xcode that is compatible with a macOS version only contains the next major macOS SDK. We do have a MacOSX.sdk port which ports could depend on if they needed a specific SDK, but there is no support from MacPorts base for doing that so there's a bit of code that would need to be added to each portfile to do that so it's a bit inconvenient.

Using the last Xcode that contains the matching SDK causes other ports to fail to build, namely those that require a newer compiler. Most of those ports are well served by the compiler blacklist mechanism which allows MacPorts to install and use a newer compiler. We used to have a problem where the compiler blacklist mechanism did not work with ports that build using xcodebuild. I don't recall whether that is still the case. If so, the advantage to our current strategy is that users can overcome the problem by building from source on their system after installing the latest Xcode, which is typically what users have anyway since that's what you get when you install from the App Store. If we instead used the latest Xcode on the buildbot workers, users could only work around builds that failed due to SDK mismatch with the much more inconvenient step of downgrading their Xcode—or we could get around to figuring out how to employ the MacOSX.sdk port in those ports that need it.