mame: @0.227 build failure on macOS 10.13 and Xcode 9.4.1, due to aligned_alloc

[mascguy (Christopher Nielsen)]

Mame 0.227 is failing to build on our infrastructure, with the combination of macOS 10.13 and Xcode 9.4.1. That's due to the use of C++ aligned_alloc.

However, builds succeed on macOS 10.13, when using Xcode 10.1.

Note that Mame is utilizing macports-clang-9 for compilation, which supports aligned_alloc. So I suspect the macOS SDK provided by Xcode is the culprit.

Presently investigating whether there is a fix for Xcode 9.4.1.

[mascguy (Christopher Nielsen)]

All you LLVM Maestros out there, particularly Ken and Jeremy: Are you folks familiar with the interplay here, relative to what's causing the failures?

Specifically, this is what I'm talking about:

error: aligned deallocation function of type 'void (void *, std::align_val_t) noexcept' is only available on macOS 10.14 or newer

Based on my research, it sounds like the LLVM project originally included this error for macOS 10.13... and then realized that aligned allocations *are* supported on 10.13 after all.

This patch spells it out:

​https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190408/267837.html

So is this an unpatched issue with our clang/llvm... an issue related to the macOS SDK provided by Xcode... ?

(To reiterate, Mame is being built with macports-clang-9, at least on macOS 10.13.)

Any help/thoughts would be much appreciated. Thanks folks!

[kencu (Ken)]

I have fixed a few of these.

The blocks are put in to the llvm tree based on the capabilities of libc++.dylib at the time (or maybe based on an error), then libc++.dylib on 10.13 is updated, and the block is no longer accurate.

These are super easy to fix, but requiring recompiling all of the clang-N's for what amounts to a 3 digit change in one __config file.

See <​https://github.com/llvm/llvm-project/blob/6529d7c5a45b1b9588e512013b02f891d71bc134/libcxx/include/__config#L393> for the tiny tiny little change needed.

[mascguy (Christopher Nielsen)]

So in terms of the logistics to fix this, the next step(s) are...?

[kencu (Ken)]

install xcode 10 on 10.13?

:>

[mascguy (Christopher Nielsen)]

Replying to kencu:

install xcode 10 on 10.13?

:>

Well, that would certainly be the simplest solution. LOL. Can I assign the enhancement request to you? ;-)

[kencu (Ken)]

Ryan is not ready for that yet :>

[mascguy (Christopher Nielsen)]

Jokes aside, do you know whether our buildbots support side-by-side Xcode installations?

I ask, as that's how some of my macOS installations are setup, when it's necessary to test against multiple Xcode releases. So for macOS 10.13, this is my setup:

/Applications/Xcode-9.4.1.app
/Applications/Xcode-10.1.app
/Applications/Xcode.app -> Xcode-10.1.app

Presently it's a bit kludgy, as I change the Xcode.app softlink to switch between them.

Anyhow, it would be awesome if the buildbots supported this, driven by a portfile declaration. Though a global Xcode.app softlink certainly wouldn't work, when multiple builds are running concurrently. But if said declaration properly sets envvar DEVELOPER_DIR, would that be enough...?

Your thoughts?

[kencu (Ken)]

Well you also have to change the command line tools for it to be right, so that is harder.

[kencu (Ken)]

According to our existing statistics, almost all 10.13 users have Xcode10 installed. The buildbot builds with Xcode9.

So that pretty much throws the entire "reproducible builds" discussion right out the window :>

There are some issues building i386 software with Xcode10 that Ryan is trying to avoid, along with the MacOSX10.14.sdk that comes with Xcode10 showing functions that are not actually available on the 10.13 system, and that causes configure errors.

I get the issue.

The fact that the buildbot builds most things using Xcode9, and users can build most of the rest themselves using Xcode10, is actually not a bad compromise (with all it's warts).

What we DON'T want to do is to start making big decisions about what port versions and builds are supported on 10.13 based on the buildbot. That is just wrong, at present.

So having someone come along and disable the qt5-qtwebkit build on 10.13 thinking they are doing a good thing because it failed on the buildbot is just wrong, because almost 100% of MacPorts users can actually build it, as they almost all have Xcode 10 installed.

[mascguy (Christopher Nielsen)]

Replying to kencu:

The fact that the buildbot builds most things using Xcode9, and users can build most of the rest themselves using Xcode10, is actually not a bad compromise (with all it's warts).

Agreed. However, for a port like Mame - which takes hours to build, on older/slower Macs - we really need to publish binaries. The question is, how can we get there, without too much disruption to our infrastructure?

[mascguy (Christopher Nielsen)]

The easy fix is to build Mame release 0.226, rather than 0.227, on macOS 10.13. Given that 0.226 is only a few months old, this seems like a reasonable near-term compromise.

Pull request created:

​https://github.com/macports/macports-ports/pull/9704

[Christopher Nielsen <mascguy@…>]

In f5b8447521ffa1e79de726a6f904b4955618bac5/macports-ports (master):

mame: fix for macOS 10.13 builds; portfile cleanup

Fixes: #62049
Fixes: #61739