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 qemu-devel@nongnu.org and qemu-triv...@nongnu.org
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 <ler...@redhat.com> 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 >
