[MacPorts] #61775: mame: 0.226 build fails on 10.8, due to C header /usr/include/xlocale/_stdio.h, snprintf_l(), etc (was: mame: 0.226 build fails on 10.8; libc++ issue?)

[MacPorts]

#61775: mame: 0.226 build fails on 10.8, due to C header
/usr/include/xlocale/_stdio.h, snprintf_l(), etc
----------------------+----------------------
  Reporter:  mascguy  |      Owner:  mascguy
      Type:  defect   |     Status:  assigned
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:
Resolution:           |   Keywords:
      Port:  mame     |
----------------------+----------------------
Description changed by mascguy:

Old description:

> 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);
>                ^
> }}}
>
> The issue appears to relate to the libc++ headers: When '_XOPEN_SOURCE'
> is defined, certain items aren't declared unless '_DARWIN_C_SOURCE' is
> also defined. So far, this bug seems to be isolated to MacOS 10.8.x.
>
> Note that the Mame port is presently using MacPorts Clang 9. However, the
> same failures also occur with MacPorts Clang 10.
>
> Potential solution: Patch source file 'posixfile.cpp', adding the
> following at the appropriate place:
>
> {{{
> // MacPorts: Fix for libc++ compilation errors on MacOS 10.8
> #if defined(__APPLE__)
> #define _DARWIN_C_SOURCE
> #endif
> }}}
>
> While we could certainly define '_DARWIN_C_SOURCE' globally, that seems
> more risky. Particularly given that the issue only affects one Mame
> source file.
>
> I've confirmed that the proposed fix allows Mame to build successfully,
> on MacOS 10.8.

New description:

 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.

--

-- 
Ticket URL: <https://trac.macports.org/ticket/61775#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS