mame: 0.226 build fails on 10.8, due to C header /usr/include/xlocale/_stdio.h, snprintf_l(), etc

[mascguy (Christopher Nielsen)]

Mame 0.226 fails to build on 10.8, due to compilation errors in file src/osd/modules/files/posixfile.cpp.

Here's one example:

In file included from ../../../../../src/osd/modules/file/posixfile.cpp:41:
In file included from ../../../../../src/osd/modules/file/posixfile.h:12:
In file included from ../../../../../src/osd/osdcore.h:17:
In file included from ../../../../../src/lib/util/strformat.h:174:
In file included from ../../../../../src/lib/util/vecstream.h:25:
In file included from /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/istream:163:
In file included from /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/ostream:140:
/opt/local/libexec/llvm-9.0/bin/../include/c++/v1/locale:1455:16: error: use of undeclared identifier 'snprintf_l'; did you mean 'vswprintf_l'?
    int __nc = __libcpp_snprintf_l(__nar, sizeof(__nar), _LIBCPP_GET_C_LOCALE, __fmt, __v);
               ^

Root cause appears to be preprocessor logic within C header file /usr/include/xlocale/_stdio.h, determining whether additional stdio functions are defined. One of those being snprintf_l().

Findings:

• In later MacOS/Xcode releases, the logic is #if __DARWIN_C_LEVEL >= 200112L || defined(__cplusplus). The latter condition ensures we don't have to worry about __DARWIN_C_LEVEL.
• But under MacOS 8.x, the logic is simply #if __DARWIN_C_LEVEL >= 200112L, with no awareness of C++ code. This breaks the Mame build.

For now, patching Mame source file posixfile.cpp is the easy fix. We simply have to appropriately define __DARWIN_C_LEVEL, or _DARWIN_C_SOURCE. I can confirm that the latter works, and the former certainly should as well.

Note: I'd prefer not to globally define anything, since the issue is limited to a single source file. There's too much risk, and it's simply not needed elsewhere.

[mascguy (Christopher Nielsen)]

<After additional investigation, this comment no longer relevant.>

[ryandesign (Ryan Carsten Schmidt)]

MacPorts uses libc++ by default on 10.6 and later. Are you sure that mame is using libstdc++? If it is, that is a bug that should be fixed; it should use the C++ stdlib that MacPorts tells it to.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

MacPorts uses libc++ by default on 10.6 and later. Are you sure that mame is using libstdc++? If it is, that is a bug that should be fixed; it should use the C++ stdlib that MacPorts tells it to.

No, you're right... Mame is using libc++, rather than libstdc++.

However, more digging revealed this to be a C header file issue... completely unrelated to the C++ standard library.

[mascguy (Christopher Nielsen)]

In addition to verifying the build fix, I've also confirmed that Mame runs successfully on MacOS 10.8.5.

[mascguy (Christopher Nielsen)]

Ryan/Anyone, now that the true root cause has been determined -- and thankfully it's in the host C header files, rather than libc++/LLVM -- any thoughts on the proposed solution?

[kencu (Ken)]

It's quite routine to define _DARWIN_C_SOURCE on macOS to get all the available functionality macOS offers.

The more restrictive feature blocker settings are usually for developers to use, to make sure their software will work on a broad array of systems they don't actually test on.

[mascguy (Christopher Nielsen)]

Sounds good Ken! I'll create a patch and submit a pull request.

[mascguy (Christopher Nielsen)]

Pull request created:

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

[mascguy (Christopher Nielsen)]

Submitted issue to the Mame project, along with a pull request:

​https://github.com/mamedev/mame/issues/7536

​https://github.com/mamedev/mame/pull/7537

[mascguy (Christopher Nielsen)]

Pull request approved by Mame maintainers, and fix merged into master.

[mascguy (Christopher Nielsen)]

Great News! Mame successfully built for all pre-Big Sur Intel x64 targets! And we can close this ticket.

[kencu (Ken)]

good work; thanks for your persistence.