> On May 2, 2022, at 2:02 PM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us>
> wrote:
>
> On Mon, 2 May 2022, Philip Prindeville wrote:
>
>> Hi,
>>
>> I was wondering how to do discovery of functions like open_memstream() which
>> is only exposed by <features.h> when compilation used -D_GNU_SOURCE or
>> -D_POSIX_C_SOURCE=200809L.
>>
>> It might be the case that I compile everything with a certain flag, or I
>> might just compile one-off modules such as:
>>
>> time.o: _ASTCFLAGS+=-D_XOPEN_SOURCE=700
>>
>> What's best practices for handling situations like this?
>>
>> How do I bracket a particular AC_CHECK_FUNCS() invocation with defines that
>> might be critical?
>>
>> I tried using:
>>
>> save_CFLAGS="$CFLAGS"
>> CFLAGS="CFLAGS -D_POSIX_C_SOURCE=200809L"
>> AC_CHECK_FUNCS([open_memstream])
>> CFLAGS="$save_CFLAGS"
>
> Normally one should use CPPFLAGS rather than CFLAGS for options pertaining to
> the C pre-processor.
Noted... and the comment about the missing '$' in the other message...
Turns out that I don't need this... AC_USE_SYSTEM_EXTENSIONS is causing it to
be exposed.
> When library function availability is checked, it is normally done using the
> linker.
>
> When in doubt, check config.log, which will show the test program and steps
> which were used while performing the test.
>
> It is not wise to mix C/OS standard influencing pre-processor options when
> compiling since they may require a different ABI, which could be provided by
> alternate libraries. It might not be possible to support more than one ABI
> at a time.
>
> Bob
Hmm... good point.
-Philip
