mame: update to 0.227

[mascguy (Christopher Nielsen)]

Also include user experience improvements, covered by issue:61743

[mascguy (Christopher Nielsen)]

The update looked like it might go smoothly, until building on MacOS 10.12: Compilation errors were encountered due to the use of C++ 2017's new aligned allocation support. (Via align_value_t and friends.) And apparently this is not supported in MacOS libc++ prior to 10.13. Ugh!

Reached out to the Mame devs, and Mame 0.227 onward is only supported for MacOS 10.14 and later: ​https://github.com/mamedev/mame/issues/7629

In terms of workarounds, compiler flag -fno-aligned-allocation could be used. Unfortunately, that means certain features will cause Mame to crash, due to misaligned memory structures. So that's not really acceptable.

Thoughts/comments welcome, as always.

[kencu (Ken)]

that's a shame.

Lots of misinformation on those pages.

MacPorts can install and use a newer libc++ ; we do it all the time on 10.6, and it is optionally available for newer systems now.

I can install a newer libc++ in parallel with the system version for MP use as well; up to now there has been no need, however.

So compiler needs are overcomeable, but if they start using only 10.14+ SDK calls, then older systems are baked Alaska, for the most part.

[mascguy (Christopher Nielsen)]

Thankfully the Mame folks don't appear to be using newer MacOS API calls, they've simply moved on to C++ 2017. So if we can use a newer libc++, that would be great!

How is that done?

[kencu (Ken)]

The referenced chain of messages <​https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=118262#Post118262> indicates the newer API calls are shortly coming. Once software starts moving to new API, you're really in a lot of trouble on older systems that that is often difficult to replicate (although we surely do it often enough :>).

Regarding the libc++ capabilities part of this, libc++ is part of llvm/clang/libomp. libc++ and libc++abi are built during the build of every macports-clang-N version. Up until now, we just haven't bothered to install them, as there was no need.

the current libcxx port allows you to install a newer libc++ and libc++abi on older systems; I do this with 10.7 now, for experimentation.

For mainline MacPorts use, what we would do is select one of the libc++ versions from the llvm tree -- exactly like we do now with libstdc++ from gcc -- and install it into some directory we choose, most likely something like:

/opt/local/lib/libcxx

and then we would sort out the method to have ports use it, either with DYLD_LIBRARY_PATH to find that one first, or alternately to build against that library directly with some proper flags to be set.

There are no parts of this that need to be discovered -- all of them use existing technology -- but we haven't as yet set up the flags, PortGroup, etc as so far we haven't needed it.

[mascguy (Christopher Nielsen)]

So to replace the system libc++, install libcxx +replacemnt_libcxx, and then copy the contents of /opt/local/var/system_roots/libcxx-5.0.1-4.tgz to:

/usr/include/cxxabi.h
/usr/include/__cxxabi_config.h
/usr/lib/libc++.1.dylib
/usr/lib/libc++.dylib -> libc++.1.dylib
/usr/lib/libc++abi.dylib

(After backing up those files first, of course...)

Is that all that's necessary?

It looks like the port will take care of that automatically, for MacOS 10.6 and earlier. Is the plan to eventually have that variant do the replacement for all MacOS releases?

[mascguy (Christopher Nielsen)]

Of note, for MacOS 10.14, the install is failing with the following error. (I deselected the universal variant.)

ld: can't map file, errno=22 file '/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk' for architecture x86_64

Is this due to the soft linking of the SDK?

$ ls -lh /Library/Developer/CommandLineTools/SDKs/
drwxr-xr-x  7 root  wheel  -  238B Jul  8 20:07:48 2019 MacOSX.sdk
lrwxr-xr-x  1 root  wheel  -   10B Jun  7 19:17:11 2020 MacOSX10.14.sdk -> MacOSX.sdk

I wasn't planning on replacing libc++ for MacOS 10.14 and 10.15 anyway, but just figured I'd ask...

[mascguy (Christopher Nielsen)]

So the $100,000 question is... what do we do for this port? While there's no rush to update Mame to 0.227, it would be nice not to leave this hanging for too long, either...

[kencu (Ken)]

Replying to mascguy:

So to replace the system libc++, install libcxx +replacemnt_libcxx, and then copy the contents of /opt/local/var/system_roots/libcxx-5.0.1-4.tgz to:

/usr/include/cxxabi.h
/usr/include/__cxxabi_config.h
/usr/lib/libc++.1.dylib
/usr/lib/libc++.dylib -> libc++.1.dylib
/usr/lib/libc++abi.dylib

Yes, basically that is it. Then reboot, and cross your fingers. You should be able to back out of the changes using Firewire Disk mode, or a recovery boot with the Terminal, if disaster ensued.

I have a 10.7 system that is running this now. It works. It crashed once -- I could not determine if the new libc++ was related to that crash.

It looks like the port will take care of that automatically, for MacOS 10.6 and earlier. Is the plan to eventually have that variant do the replacement for all MacOS releases?

Probably not. 10.6 has no libc++.dylib, so that was low-hanging fruit.

For newer systems, the only fix that MacPorts would likely support is the parallel installation of a newer libc++ (and related parts) from llvm-9 or llvm-10 say, and then as above, force it to be used instead of the system libc++ via some trickery.

[kencu (Ken)]

Replying to mascguy:

Of note, for MacOS 10.14, the install is failing with the following error. (I deselected the universal variant.)

ld: can't map file, errno=22 file '/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk' for architecture x86_64

Is this due to the soft linking of the SDK?

$ ls -lh /Library/Developer/CommandLineTools/SDKs/
drwxr-xr-x  7 root  wheel  -  238B Jul  8 20:07:48 2019 MacOSX.sdk
lrwxr-xr-x  1 root  wheel  -   10B Jun  7 19:17:11 2020 MacOSX10.14.sdk -> MacOSX.sdk

I wasn't planning on replacing libc++ for MacOS 10.14 and 10.15 anyway, but just figured I'd ask...

I don't think this error was due to soft linking of the SDK.

I have seen this error before but I can't just now recall what caused it.

For errors like this, I usually go into the build tree, and manually run the failing command (the entire command) in the build tree, sometimes adding some verbose flags to the failing line until I figure out what is going on.

Sorting this out by running high level "sudo port -v install" commands doesn't always work.

[kencu (Ken)]

Replying to mascguy:

So the $100,000 question is... what do we do for this port? While there's no rush to update Mame to 0.227, it would be nice not to leave this hanging for too long, either...

I suggest: update your port as you wish. If older systems lose the capability to build it, that is life. Mark them as not building. Provide a fallback version 0.226 for them if you're generous.

If there is interest and motivation to come up with a plan to fix that, that will happen organically.

For this problem, we will most likely come up with a fix for the older libc++ on older systems, as soon that will affect many ports.

[mascguy (Christopher Nielsen)]

Replying to kencu:

Provide a fallback version 0.226 for them if you're generous.

Yes definitely, I'll retain/maintain 0.226, since it builds and runs from 10.6 through 10.15.

As for supporting an alternate libc++ within the MacPorts tree, let me know if there's anything I can do to help. Ditto for anything else, including the overall Apple Silicon porting effort.

[mascguy (Christopher Nielsen)]

Pull request created:

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

[Christopher Nielsen <mascguy@…>]

In 9c7d3582b8f2511b1d22b60ddf94062f015e31be/macports-ports (master):

mame: update for 0.227; update launch script to improve user experience

Fixes: #61976
Fixes: #61743