| Summary: | app-emulation/qemu +ncurses fails to compile in hardened/linux/musl/amd64 profile | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Chad Joan <chadjoan> |
| Component: | Hardened | Assignee: | Gentoo musl team <musl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | herrtimson, tsmksubc |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 430702 | ||
| Attachments: |
build.log
emerge --info '=app-emulation/qemu-2.8.0-r1::musl' emerge -pqv '=app-emulation/qemu-2.8.0-r1::musl' qemu-2.8.0-musl-ncurses.patch |
||
Created attachment 463764 [details]
build.log
Created attachment 463766 [details]
emerge --info '=app-emulation/qemu-2.8.0-r1::musl'
Created attachment 463768 [details]
emerge -pqv '=app-emulation/qemu-2.8.0-r1::musl'
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? 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 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. 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? 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". Created attachment 463798 [details, diff]
qemu-2.8.0-musl-ncurses.patch
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.
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. My bad. You are quite right. I was here: http://wiki.qemu-project.org/Contribute/SubmitAPatch 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. Upstream patch request: http://lists.nongnu.org/archive/html/qemu-trivial/2017-02/msg00076.html This patch never made it upstream it seems. Would you mind checking the current version and reopening if the problem persists? (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! (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 https://zerobin.net/?6d3abc0edd68afc6#q2rAheFBqHAQSBL1bRfyd//k9c86p6Rq20L8zMGzAdA= 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! |
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") Homepage: https://www.gnu.org/software/ncurses/ http://dickey.his.com/ncurses/ 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); add_wch(WACS_DEGREE); 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] add_wch(WACS_DEGREE); ^ 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) add_wch(WACS_DEGREE); ^ 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); add_wch(WACS_DEGREE); 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: https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg07898.html