Re: [Qemu-devel] Fix build break during configuration on musl-libc based Linux systems.

[Laszlo Ersek <lersek@redhat.com>]

On 02/17/17 09:56, Paolo Bonzini wrote:
> 
> 
> On 16/02/2017 18:23, Laszlo Ersek wrote:
>> On 02/16/17 17:58, Paolo Bonzini wrote:
>>>
>>>
>>> On 16/02/2017 17:30, Chad Joan wrote:
>>>> Hello,
>>>>
>>>> This is a one-line patch to the configure script that will allow QEMU to be
>>>> built on musl-libc based Linux systems.  This problem is only noticeable
>>>> when QEMU is built with --enable-curses.
>>>>
>>>> Detailed reading material if you want to know where this came from:
>>>> https://bugs.gentoo.org/show_bug.cgi?id=609364
>>>
>>> Hi,
>>>
>>> can you explain exactly which function is missing without
>>> -D_XOPEN_SOURCE=500?  If it is curses' wide-char functions, why does it
>>> fail with musl but not with glibc?  Is _XOPEN_SOURCE always defined by
>>> glibc if you have _D_GNU_SOURCE?
>>
>> It is not necessarily auto-defined, but the effect is "as if".
> 
> Ok, so the bug is that glibc _does_ auto-define _XOPEN_SOURCE:
> 
> #ifdef _GNU_SOURCE
> # undef  _ISOC95_SOURCE
> # define _ISOC95_SOURCE 1
> # undef  _ISOC99_SOURCE
> # define _ISOC99_SOURCE 1
> # undef  _ISOC11_SOURCE
> # define _ISOC11_SOURCE 1
> # undef  _POSIX_SOURCE
> # define _POSIX_SOURCE  1
> # undef  _POSIX_C_SOURCE
> # define _POSIX_C_SOURCE        200809L
> # undef  _XOPEN_SOURCE
> # define _XOPEN_SOURCE  700
> # undef  _XOPEN_SOURCE_EXTENDED
> # define _XOPEN_SOURCE_EXTENDED 1
> # undef  _LARGEFILE64_SOURCE
> # define _LARGEFILE64_SOURCE    1
> # undef  _DEFAULT_SOURCE
> # define _DEFAULT_SOURCE        1
> # undef  _ATFILE_SOURCE
> # define _ATFILE_SOURCE 1
> #endif
> 
> and ncursesw looks for _XOPEN_SOURCE exclusively:
> 
> #ifndef NCURSES_WIDECHAR
> #if defined(_XOPEN_SOURCE_EXTENDED) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE - 0 >= 500))
> #define NCURSES_WIDECHAR 1
> #else
> #define NCURSES_WIDECHAR 0
> #endif
> #endif /* NCURSES_WIDECHAR */
> 
> 
> So I do think that if musl wants to support _GNU_SOURCE, it should also auto-define;
> however it doesn't, see https://git.musl-libc.org/cgit/musl/tree/include/features.h.
> 
> Alternatively, ncurses should be patched to look at _GNU_SOURCE in addition to
> _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED.
> 
> In any case, it's not a QEMU bug.  Other packages likely are going to have the same
> issue, and fixing all of them is the wrong course of action.

I'm somewhat unsure -- I think it's debatable whether other libc (or
Curses) implementations should care about _GNU_SOURCE at all. After all,
_GNU_SOURCE says "GNU" in the name.

However, defining _XOPEN_SOURCE as 500 is specified in an industry
standard (SUSv2):

http://pubs.opengroup.org/onlinepubs/7908799/xsh/compilation.html

and the same standard defines Curses too (and it describes the
relationship of Curses interfaces with _XOPEN_SOURCE):

http://pubs.opengroup.org/onlinepubs/7908799/xcurses/implement.html

So I think if an application wants to support Curses *without*
necessarily depending on glibc, then the application should explicitly
define _XOPEN_SOURCE. If that other libc and that Curses implementation
don't care about GNU, only SUSv2 (which is entirely in their right),
then they'll look only for _XOPEN_SOURCE.

And, if other packages have the same issue, then they all should be
patched, for better standards conformance.

Of course, *if* that other C library, and the Curses implementation,
claim compatibility with glibc as far as _GNU_SOURCE goes, *then* I
fully agree with you. (IOW, it depends on the condition that you
formulated above, "if musl wants to support _GNU_SOURCE".)

Same for ncurses -- do they aim at SUSv2 conformance, or do they intend
to consider _GNU_SOURCE specifically?

Thanks
Laszlo