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

MacPorts noreply at macports.org
Tue Dec 8 05:38:58 UTC 2020


#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);
>                ^
> }}}
>
> 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.

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:10>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list