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

[Chad Joan]

Sure.

I'll see your -O2 and raise you a -c ;)

It went like this:

$ gcc -c first.c -O2
$ gcc -c second.c -O2
$ gcc -c third.c -O2

No complaints from gcc whatsoever (unless I drop the -c, then ld complains
about the undefined reference to main, which I think we all expect).

Just incase you expected one of them to fail (ex: as a control test), I
verified that the original snippet from the configure script still causes
an error on the system:
#########
$ cat << EOF > reference.c
> #include <locale.h>
> #include <curses.h>
> #include <wchar.h>
> int main(void) {
>   const char *s = curses_version();
>   wchar_t wch = L'w';
>   setlocale(LC_ALL, "");
>   resize_term(0, 0);
>   addwstr(L"wide chars\n");
>   addnwstr(&wch, 1);
>   add_wch(WACS_DEGREE);
>   return s != 0;
> }
> EOF
$ gcc reference.c -O2
reference.c: In function 'main':
reference.c:11:11: error: 'WACS_DEGREE' undeclared (first use in this
function)
   add_wch(WACS_DEGREE);
           ^
reference.c:11:11: note: each undeclared identifier is reported only once
for each function it appears in
#########

Hope that helps.

On Fri, Feb 17, 2017 at 6:11 AM, Paolo Bonzini <address@hidden> wrote:

>
>
> On 17/02/2017 10:17, Laszlo Ersek wrote:
> > 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".)
>
> They at least try, since their features.h supports it.
>
> > Same for ncurses -- do they aim at SUSv2 conformance, or do they intend
> > to consider _GNU_SOURCE specifically?
>
> Well, ncurses is a GNU project so I suppose they mostly care about
> whatever Autoconf does.  And indeed Autoconf does have some special
> casing for -D_XOPEN_SOURCE=500:
>
>   AC_CACHE_CHECK([whether _XOPEN_SOURCE should be defined],
>     [ac_cv_should_define__xopen_source],
>     [ac_cv_should_define__xopen_source=no
>      AC_COMPILE_IFELSE(
>        [AC_LANG_PROGRAM([[
>           #include <wchar.h>
>           mbstate_t x;]])],
>        [],
>        [AC_COMPILE_IFELSE(
>           [AC_LANG_PROGRAM([[
>              #define _XOPEN_SOURCE 500
>              #include <wchar.h>
>              mbstate_t x;]])],
>           [ac_cv_should_define__xopen_source=yes])])])
>   test $ac_cv_should_define__xopen_source = yes &&
>     AC_DEFINE([_XOPEN_SOURCE], [500])
>
> If musl needs _XOPEN_SOURCE for wchar.h, then it would be worth working
> around in QEMU.  If it's just happening with ncurses, however, it'd be a
> musl bug, which should be fixed in musl or worked around in ncurses.
>
> Chad, can you check whether the programs below fails with musl:
>
> /* First program */
> #define _GNU_SOURCE
> #include <wchar.h>
> mbstate_t x;
>
> /* Second program */
> #include <wchar.h>
> mbstate_t x;
>
> /* Third program */
> #define _XOPEN_SOURCE 500
> #include <wchar.h>
> mbstate_t x;
>
> Just compile them with "gcc foo.c -O2".
>
> Thanks,
>
> Paolo
>