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

[Thomas Dickey]

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.

> >>>> +(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.

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.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature