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 <pbonz...@redhat.com> 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 >