[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:37:45 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:9>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list