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

[Chad Joan]

I am glad others are chiming in and might provide better solutions.

Honestly, following the instructions at http://wiki.qemu-project.org/Contribute/SubmitAPatch to-the-letter is quite daunting to me, just to get one line of code changed.  It might help if that page had some kind of dead-simple example for trivial patches; something like:

$ cd <QEMU directory>

$ git format-patch blah blah blah

$ maybe-some-other-command

$ # Now copy the contents of file xyz.patch into your email client and send to address@hidden and address@hidden

Ask me to do signing/secure-signatures/etc (or any foray into gnupg commands), setup and secure new email connectivity (ex: git send-email), or install new software on my system... and I'm going to bounce ;)  Sorry.

I kind of expected that discerning maintainers might want to do this patch differently.  I'm not familiar with the why's of how your configure script is organized, so I really hope the QEMU devs can meet me in the middle and take this the rest of the way.  I am perfectly willing to run commands on my machine and echo results to you if it helps you learn the nature of this problem.

Hope that helps.

- Chad

On Thu, Feb 16, 2017 at 12:23 PM, Laszlo Ersek <address@hidden> 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".

It is documented in the libc info:

https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fXOPEN_005fSOURCE

> Macro: _XOPEN_SOURCE
> Macro: _XOPEN_SOURCE_EXTENDED
>
>     If you define this macro, functionality described in the X/Open
>     Portability Guide is included. This is a superset of the POSIX.1
>     and POSIX.2 functionality and in fact _POSIX_SOURCE and
>     _POSIX_C_SOURCE are automatically defined.
>
>     As the unification of all Unices, functionality only available in
>     BSD and SVID is also included.
>
>     If the macro _XOPEN_SOURCE_EXTENDED is also defined, even more
>     functionality is available. The extra functions will make all
>     functions available which are necessary for the X/Open Unix brand.
>
>     If the macro _XOPEN_SOURCE has the value 500 this includes all
>     functionality described so far plus some new definitions from the
>     Single Unix Specification, version 2.

https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fGNU_005fSOURCE

> Macro: _GNU_SOURCE
>
>     If you define this macro, everything is included: ISO C89, ISO
>     C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions.
>     In the cases where POSIX.1 conflicts with BSD, the POSIX
>     definitions take precedence.

Curiously, I managed to recall this from years ago, when I was still
living and breathing the SUS (and looking frequently at the glibc info too).

Laszlo