https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
frankhb1989 at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |frankhb1989 at gmail dot com
--- Comment #41 from frankhb1989 at gmail dot com ---
I ran into exact the same trouble of C23 missing symbols on old systems. In my
case it is a custom build (with tailored source) of libfreeimage which has some
calls to `sscanf` pulling the unwanted symbol references (to
`__isoc23_sscanf@GLIBC_2.38`) into the library. As said, the root cause is PR
11196. However, for this specific case `-U_GNU_SOURCE -D_ISOC99_SOURCE
-D_POSIX_C_SOURCE=200809L` can just work for me, because all sites using the
function are known exhaustively.
The (un)interesting part is how to figure out the concrete feature sets need to
be used. In fact, the workaround here follows the fix in
https://sourceware.org/bugzilla/show_bug.cgi?id=21326. However, despite that
bug is marked fixed, it actually misses `__USE_ISOC95` so names like `::fwide`
will not be properly declared. That's why `_ISOC99_SOURCE` is needed here.
Similarly, `_POSIX_C_SOURCE` is needed for `uselocale`.
Such options should work as per platform ABI and the semantics of
`_XXX_SOURCE`, in spite of the fact of unsupported status by GCC. The mismatch
of runtime library and headers looks scary, but still feasible for
compatibility purpose, working like dual-ABI libstdc++ in some degrees. That
said, it requires the knowledge of the way to use symbols in the client code.
Use at ones' own risks.
