Re: [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
>