Re: Missing -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 in pkg-config files in Clang + LLVM environment?

[Sam James]

> On 10 Sep 2022, at 18:48, Thomas Dickey <dickey@his.com> wrote:
> 
> On Sat, Sep 10, 2022 at 04:55:57PM +0100, Sam James wrote:
>> 
>> 
>>> On 10 Sep 2022, at 16:48, Thomas Dickey <dickey@his.com> wrote:
>>> 
>>> On Sat, Sep 10, 2022 at 02:47:50PM +0100, Sam James wrote:
>>>> 
>>>> 
>>>>> On 10 Sep 2022, at 14:11, Thomas Dickey <dickey@his.com> wrote:
>>>>> 
>>>>> On Fri, Sep 09, 2022 at 01:49:05AM +0100, Sam James wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 9 Sep 2022, at 01:02, Sam James <sam@gentoo.org> wrote:
>>>>>>> [snip]
>>>>>>> 
>>>>>>>>> This is on a musl + Clang system (details below for how
>>>>>>>>> to reproduce).
>>>>>>>> 
>>>>>>>> none of the systems that I develop on have musl.
>>>>>>>> (you're free to submit a patch, if you use musl).
> 
> actually, I see that Debian has a package (which has a few limitations...).
> So I needn't find an embedded system to develop on.

You could've just grabbed the Gentoo stage3 I linked (no need to install,
just untar /tmp and chroot in), but I asked #musl for recommendations
and they said http://musl.cc/ or https://github.com/richfelker/musl-cross-make
might probe helpful too.

I can probably set up access to a clean machine if you need it as well,
if push comes to shove.

But glad you've got something to use!

> 
>>>>>> +(linux*musl*)
>>>>>> +        CF_TRY_XOPEN_SOURCE
>>>>>> +        ;;
>>>>> 
>>>>> that part looks right
>>>>> 
>>>>>> (linux*|uclinux*|gnu*|mint*|k*bsd*-gnu|cygwin)
> 
> actually if I change "linux*" to "linux*gnu", that'll let me use the
> default case and save a few lines of script.
> 
>>>>>>  CF_GNU_SOURCE($cf_XOPEN_SOURCE)
>>>>>>  ;;
>>>>>> ```
>>>>>> 
>>>>>> It's insufficient because it thinks we don't need to set it.
>>>>>> 
>>>>>> Apparently this is because when building a test program
>>>>>> with
>>>>>> #include <stdlib.h>
>>>>>> #include <string.h>
>>>>>> #include <sys/types.h>
>>>>>> This ends up enabling XOPEN_SOURCE (some header
>>>>>> is defining it, I guess).
>>> 
>>> one or more of these should be defining _XOPEN_SOURCE
>>> (I'd expect the first, of course).
>>> 
>> 
>> It looks like /usr/include/features.h is the only libc header defining it
>> on this system, with a hacky grep:
>> ```
>> # grep -rsin "#define.*_XOPEN_SOURCE" /usr/include
>> /usr/include/features.h:16:#define _XOPEN_SOURCE 700
> 
> features.h is where to read about the GNU library.
> musl has its own header files (comparing them should give some insight).
> 
>> /usr/include/awk/awk.h:47:#define _XOPEN_SOURCE_EXTENDED 1
>> /usr/include/awk/custom.h:92:#define _XOPEN_SOURCE_EXTENDED 1
>> /usr/include/python3.10/pyconfig.h:1720:#define _XOPEN_SOURCE 700
>> /usr/include/python3.10/pyconfig.h:1723:#define _XOPEN_SOURCE_EXTENDED 1
>> /usr/include/python3.11/pyconfig.h:1867:#define _XOPEN_SOURCE 700
>> /usr/include/python3.11/pyconfig.h:1870:#define _XOPEN_SOURCE_EXTENDED 1
>> ```
>> 
>> features.h: http://sprunge.us/cNkSTH.
> 
> I see... Actually the problem that I see is different.  Normally with
> Linux, building ncursesw will require the _DEFAULT_SOURCE and _XOPEN_SOURCE
> symbols to be provided.  musl (looking at package in Debian) has that
> hard-coded, veering away from the standard (applications, _not_ the
> library, are supposed to define these symbols):
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02
> 
> So ncurses will build without the symbols being defined.

Right.

> 
> However, the curses.h header file will only turn on the wide-character
> definitions if _XOPEN_SOURCE or NCURSES_WIDECHAR is defined.  Since
> neither is automatically put into the ".pc" files, nothing seems to
> happen.  (The ncurses test-programs built in-tree work fine).
> 
> I can make this work as expected by supplying -DNCURSES_WIDECHAR
> via the ".pc" file.

This sounds like it'll work, and it makes sense.

Thanks for your help on this.

Best,
sam

signature.asc
Description: Message signed with OpenPGP