Previously two commits added a fallback fmemopen for OS X/BSD that
didn't support fmemopen, then fixed some of the ifdef logic around it.
Unforunately the logic was backwards, as libc implementations do not
define _POSIX_C_SOURCE in order to advertise features. Instead the
user defines _POSIX_C_SOURCE to control which definitions are
available.
Check _POSIX_VERSION to see if the libc is new enough to implement
fmemopen. If it is too old, assume that we're on a BSD compatible
system and use the fallback fmemopen that depends on funopen.
This solves the problem for some environments, but is still incorrect
as it will try to use the fallback even on a system that does not
include funopen.
Fixes: 45c7237 (Fixup for recent firmware inclusion changes (#34))
Fixes: 17f6b01 (Fix cross-platform building)
Fixes: #132 (Build failure on musl based system (incorrect fmemopen check))
pelwell
commented
2 years ago
Previously two commits added a fallback fmemopen for OS X/BSD that didn't support fmemopen, then fixed some of the ifdef logic around it. Unforunately the logic was backwards, as libc implementations do not define _POSIX_C_SOURCE in order to advertise features. Instead the user defines _POSIX_C_SOURCE to control which definitions are available.
Check _POSIX_VERSION to see if the libc is new enough to implement fmemopen. If it is too old, assume that we're on a BSD compatible system and use the fallback fmemopen that depends on funopen. This solves the problem for some environments, but is still incorrect as it will try to use the fallback even on a system that does not include funopen.
Fixes: 45c7237 (Fixup for recent firmware inclusion changes (#34)) Fixes: 17f6b01 (Fix cross-platform building) Fixes: #132 (Build failure on musl based system (incorrect fmemopen check))