Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 609364 - app-emulation/qemu +ncurses fails to compile in hardened/linux/musl/amd64 profile
Summary: app-emulation/qemu +ncurses fails to compile in hardened/linux/musl/amd64 pro...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Hardened (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Gentoo musl team
Depends on:
Blocks: musl-porting
  Show dependency tree
Reported: 2017-02-14 21:12 UTC by Chad Joan
Modified: 2019-05-24 19:43 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

build.log (build.log,4.19 KB, text/plain)
2017-02-14 21:14 UTC, Chad Joan
emerge --info '=app-emulation/qemu-2.8.0-r1::musl' (emerge-info.log,7.05 KB, text/plain)
2017-02-14 21:16 UTC, Chad Joan
emerge -pqv '=app-emulation/qemu-2.8.0-r1::musl' (emerge-pqv.log,1.11 KB, text/plain)
2017-02-14 21:17 UTC, Chad Joan
qemu-2.8.0-musl-ncurses.patch (qemu-2.8.0-musl-ncurses.patch,322 bytes, patch)
2017-02-15 08:11 UTC, Chad Joan
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chad Joan 2017-02-14 21:12:57 UTC
Both =app-emulation/qemu-2.8.0::musl and =app-emulation/qemu-2.8.0-r1::musl are failing to build when the ncurses USE flag is provided.  It builds fine without ncurses (but that makes it rather inconvenient to install VMs ;)).

The failure occurs during configuration, and it looks like this:

ERROR: User requested feature curses
       configure was not able to find it.
       Install ncurses devel

I have =sys-libs/ncurses-6.0-r1 installed on the system::

$ eix -e ncurses
[I] sys-libs/ncurses
     Available versions:
     (0)    5.9-r3 ~5.9-r4 5.9-r5(0/5) 6.0-r1(0/6)
     (5)    5.9-r99(5/5) 5.9-r101(5/5) 6.0(5/6)
       {ada +cxx debug doc gpm minimal profile static-libs test threads tinfo trace unicode ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
     Installed versions:  6.0-r1(03:58:08 02/14/17)(cxx gpm static-libs threads unicode -ada -debug -doc -minimal -profile -test -tinfo -trace ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
     Description:         console display library

When I dig into the ./configure script, I find that the "curses probe" test program is failing to compile:

Source code in config-temp/qemu-conf.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);
  return s != 0;

Compiler invocation:
cc -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/libpng16 -I/usr/include/ncursesw -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -Wl,-z,relro -Wl,-z,now -pie -m64 -g -lcursesw
config-temp/qemu-conf.c: In function 'main':
config-temp/qemu-conf.c:9:3: warning: implicit declaration of function 'addwstr' [-Wimplicit-function-declaration]
   addwstr(L"wide chars\n");
config-temp/qemu-conf.c:9:3: warning: nested extern declaration of 'addwstr' [-Wnested-externs]
config-temp/qemu-conf.c:10:3: warning: implicit declaration of function 'addnwstr' [-Wimplicit-function-declaration]
   addnwstr(&wch, 1);
config-temp/qemu-conf.c:10:3: warning: nested extern declaration of 'addnwstr' [-Wnested-externs]
config-temp/qemu-conf.c:11:3: warning: implicit declaration of function 'add_wch' [-Wimplicit-function-declaration]
config-temp/qemu-conf.c:11:3: warning: nested extern declaration of 'add_wch' [-Wnested-externs]
config-temp/qemu-conf.c:11:11: error: 'WACS_DEGREE' undeclared (first use in this function)
config-temp/qemu-conf.c:11:11: note: each undeclared identifier is reported only once for each function it appears in


I have attempted to replace the source code in config-temp/qemu-conf.c with following and recompile:
#include <locale.h>
#include <ncursesw/curses.h>   // <- NOTE: header change
#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);
  return s != 0;

Because /usr/include/ncursesw/curses.h seems to contain macro definitions for addwstr, addnwstr, and add_wch:

$ grep -RPn '(addwstr|addnwstr|add_wch)' /usr/include/ncursesw/curses.h
1641:extern NCURSES_EXPORT(int) add_wch (const cchar_t *);                      /* generated:WIDEC */
1642:extern NCURSES_EXPORT(int) add_wchnstr (const cchar_t *, int);             /* generated:WIDEC */
1643:extern NCURSES_EXPORT(int) add_wchstr (const cchar_t *);           /* generated:WIDEC */
... etc etc ...

/usr/include/curses.h doesn't contain those.

But it still generates the error messages mentioned above.  Perhaps there are some macro conditions/definitions (#define/#if) that I need to examine in ncursesw/curses.h to figure out what is happening.

I am wondering if ncurses is deploying the incorrect <curses.h> file and somewhere along the way the correct #define's aren't getting executed, but it's all complete speculation.  Unfortunately, I have no idea what any of this is /supposed/ to look like.

Possibly related upstream discussion:
Comment 1 Chad Joan 2017-02-14 21:14:08 UTC
Created attachment 463764 [details]
Comment 2 Chad Joan 2017-02-14 21:16:24 UTC
Created attachment 463766 [details]
emerge --info '=app-emulation/qemu-2.8.0-r1::musl'
Comment 3 Chad Joan 2017-02-14 21:17:10 UTC
Created attachment 463768 [details]
emerge -pqv '=app-emulation/qemu-2.8.0-r1::musl'
Comment 4 Felix Janda 2017-02-14 23:14:02 UTC
The compiler line has already "-I/usr/include/ncursesw" so
/usr/include/ncursesw/ncurses.h. This is why your change to the
configure script did not make any change.

Can you instead try adding "#define _XOPEN_SOURCE 500" to the top of
the configure test?
Comment 5 Chad Joan 2017-02-14 23:46:52 UTC
That makes sense :)

Hey, looks like that #define brings it a step closer:
cc -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/libpng16 -I/usr/include/ncursesw -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -Wl,-z,relro -Wl,-z,now -pie -m64 -g -lcursesw
/usr/lib/gcc/x86_64-gentoo-linux-musl/4.9.3/../../../../x86_64-gentoo-linux-musl/bin/ld: cannot find -lcursesw
collect2: error: ld returned 1 exit status
Comment 6 Chad Joan 2017-02-14 23:54:11 UTC
Actually that might make it work now that I've modified it inside the configure script.  Not sure how I borked linking earlier.  I'm going to play with it some more before I say anything definitive.
Comment 7 Chad Joan 2017-02-15 00:03:45 UTC
Ah, I think it was failing over to -lcursesw, which is what I tested with.  Valid for source code correction, but no way it would link on this system.

Once I placed the change into the configure script, it no longer needed to fail-over, so it went with -lncursesw instead (ncurses instead of curses) and linked successfully.

It seems to pass configuration now.

I'm going to have to do some work to integrate that with the source tarball before I can make sure that portage will build the entire package correctly with that tweak applied.

In the meantime: what does that tell us?  Any idea how I /should/ patch this or reconfigure my system to make it work in a proper way?
Comment 8 Felix Janda 2017-02-15 01:18:57 UTC
Are you sure that a one-line patch to configure does not suffice?
Look for "NCURSES_WIDECHAR" in ncursesw/curses.h to why it is necessary.

It seems to me that the configure script tries to link with the result
from pkg-config, if that does not work with "-lncursesw", or finally
with "-lcursesw".
Comment 9 Chad Joan 2017-02-15 08:11:45 UTC
Created attachment 463798 [details, diff]

Here is the patch I'm using right now.

I opted to add -D_XOPEN_SOURCE=500 to the default (Linux) CFLAGS, but not other systems.  I'm not actually sure how this would impact other non-musl Linuxes; hopefully those environments would just redefine it to whatever they normally use, but that'd be a big assumption for me to make.

It works fine for hardened-musl at least, and I had QEMU boot a VM in ncurses mode.

I also tested it on my non-musl x86_64 system (profile default/linux/amd64/13.0) by merging qemu-2.8.0-r1 without the patch (successfully), then unmerging it, then setting up a patched ebuild in my local overlay and merging it again (it succeeded while patched too).  So it might be possible to at least consider it for an upstream patch.

Speaking of upstream... I really want to be a good person and submit a patch.  But they require a mailinglist registration for patch submission.  It hits me now that if I'm going to be solving these small problems in many projects a lot, then I should find some way to prevent my inbox from having hundreds of filters and becoming a backup medium for a fraction of the internet's mailing lists.  Maybe I can sign up another email account and use it until it fills up, then pitch it and start over.  I don't even want to think about it right now, so upstream might have to wait a bit.

Anyways, thanks for the help Felix; you're awesome.
Comment 10 Felix Janda 2017-02-15 12:16:04 UTC
Adding _XOPEN_SOURCE to cflags should be very safe. The intended
purpose of this macro is to expose definitions from a specific POSIX
standard. _XOPEN_SOURCE is one of the many feature test macros.

It would be very nice if you could send a patch upstream. Are you
sure that subscription is required to post to qemu-devel? I would
just try to post without subscription. It might take some time for it
to make it onto the list because of moderation, though. Also, it is
usually possible to be subscribed without receiving list mail.
Comment 11 Chad Joan 2017-02-16 16:27:23 UTC
My bad.  You are quite right.

I was here:
I missed or forgot the "You do not have to subscribe to post" but did read and remember the "If you do subscribe, be prepared for a high volume of email, often over one thousand messages in a week."

The setup sounds pretty decent and I will give it a shot.
Comment 12 Chad Joan 2017-02-16 16:59:52 UTC
Upstream patch request:
Comment 13 Matthias Maier gentoo-dev 2019-04-08 01:39:37 UTC
This patch never made it upstream it seems. Would you mind checking the current version and reopening if the problem persists?
Comment 14 Chad Joan 2019-04-12 19:33:53 UTC
(In reply to Matthias Maier from comment #13)
> This patch never made it upstream it seems. Would you mind checking the
> current version and reopening if the problem persists?

Hi Matthias,

I have been too busy the last few days to do this, but I wanted to at least reply and let you know that I saw your request and intend to get around to it.

Thank you for checking!
Comment 15 Chad Joan 2019-05-24 19:43:39 UTC
(In reply to Matthias Maier from comment #13)
> This patch never made it upstream it seems. Would you mind checking the
> current version and reopening if the problem persists?

app-emulation/qemu-3.1.0-r4 (with ncurses USE flag set) merges fine now.

The 4.0.0 version gave me an error during build that seems unrelated:

ERROR: User requested feature docs
       configure was not able to find it.
       Install texinfo, Perl/perl-podlators and python-sphinx

I may have to ignore the 4.0.0 error for now; I don't really have time to deal with it and I don't need to run the absolute latest version. The 4.0.0 error seems like something that would be easily apparent to maintainers or already be in the tracker somewhere, but let me know if I should file a bug for that.

Given that the latest stable is building fine and the more recent version seems inhibited by something unrelated, I'll mark this as fixed.

Thanks again!