On Mon, Jun 11, 2018 at 07:46:29PM +0200, Sven Joachim wrote: > Control: tags -1 upstream > > On 2018-06-07 19:11 +0200, Jakub Wilk wrote: > > > Package: libncurses-dev > > Version: 6.1+20180210-4 > > > > The compiler flags that are supposedly needed to compile with ncurses > > include feature test macros: > > > > $ ncurses6-config --cflags > > -D_GNU_SOURCE -D_DEFAULT_SOURCE > > > > $ pkg-config --cflags ncurses > > -D_GNU_SOURCE -D_DEFAULT_SOURCE > > This has been done upstream in the 20150221 patchlevel: > > ,---- > | + capture define's related to -D_XOPEN_SOURCE from the configure check > | and add those to the *-config and *.pc files, to simplify use for > | the wide-character libraries. > `---- > > Which raises a few questions, e.g. > > - Why is this done even if ncurses is configured without --enable-widec ?
_GNU_SOURCE was defined because originally it was not possible to turn on _XOPEN_SOURCE with glibc. _XOPEN_SOURCE is needed for more than wide-characters (exactly what depends on which features on different systems are/are-not within the correct ifdef's, but a quick check shows me vsscanf for instance). So _XOPEN_SOURCE (or something like _GNU_SOURCE) is defined for most platforms whether or not wide characters are used. I could (but probably not reliably) do a test-compile with the headers to ensure that the compile-time is/is-not needed when compiling with curses.h, but that's not something I'd do in a hurry :-) With today's patch, I'm updating the configure script to reduce the need for _GNU_SOURCE (since the "recent" changes for _DEFAULT_SOURCE in 2012 made that possible). As for whether the compile-time definitions are needed in the generated config's, that's additional work. > - Why does it end up in tinfo.pc and tic.pc which (presumably) would > never need it? Those are special cases (but note that tic.h includes curses.h). I'll investigate the case for tinfo.pc, but am out of time today (it's not only Linux that uses that file). > > Please don't include them. > > _GNU_SOURCE is particularly nasty, because it can change semantics of > > some libc functions (at least sscanf and strerror_r). > > I tend to agree, but would rather not deviate from upstream, especially > since this behavior has been in place for over three years already. see above -- Thomas E. Dickey <[email protected]> https://invisible-island.net ftp://ftp.invisible-island.net
signature.asc
Description: Digital signature
