From: Pedro Alves <palves@redhat.com>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>, gdb-patches@sourceware.org
Subject: Re: Fix tui compilation with Solaris libcurses (PR tui/21482)
Date: Thu, 18 May 2017 13:19:00 -0000 [thread overview]
Message-ID: <32521e83-00b5-e2a8-faff-03b5407cfc67@redhat.com> (raw)
In-Reply-To: <yddh90i1r31.fsf@CeBiTec.Uni-Bielefeld.DE>
On 05/18/2017 09:56 AM, Rainer Orth wrote:
> On both mainline and the 8.0 branch, gdb compilation fails on Solaris 10
> with the native libcurses:
>
> * Initially, compilation failed like this:
>
> In file included from /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/gdb_curses.h:42:
> 0,
> from /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/tui/tui-data.h:2
> 6,
> from /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/tui/tui-disasm.c
> :31:
> /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/tui/tui-disasm.c: In function âCORE_A
> DDR tui_disassemble(gdbarch*, tui_asm_line*, CORE_ADDR, int)â:
> /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/tui/tui-disasm.c:71:19: error: âclass
> string_fileâ has no member named âwclearâ; did you mean âclearâ?
> gdb_dis_out.clear ();
> ^
> /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/tui/tui-disasm.c:78:19: error: âclass
> string_fileâ has no member named âwclearâ; did you mean âclearâ?
> gdb_dis_out.clear ();
> ^
> make[2]: *** [Makefile:1927: tui-disasm.o] Error 1
>
> It turned out this happens because <curses.h> has
>
> #define clear() wclear(stdscr)
>
> This can be avoided by defining NOMACROS, which the patch below does
> for solaris2.*.
We already handle some curses warts in gdb_curses.h (and then
include that header instead everywhere). I think this could go there,
even unconditionally. (This is more about curses implementation
than OS strictly speaking. Googling around finds hits for that
macro in the AIX curses.h header, for example.). Looks like ncurses
checks NCURSES_NOMACROS instead of NOMACROS, we could define that too.
>
> * Even with this workaround, compilation fails in gdb/tui for several
> instances of the same problem:
>
> /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/tui/tui-winsource.c: In function âvoid tui_erase_source_content(tui_win_info*, int)â:
> /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/tui/tui-winsource.c:257:18: error: invalid conversion from âconst char*â to âchar*â [-fpermissive]
> no_src_str);
> ^
> In file included from /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/gdb_curses.h:42:0,
> from /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/tui/tui-data.h:26,
> from /vol/src/gnu/gdb/gdb-8.0-branch/local/gdb/tui/tui-winsource.c:33:
> /vol/gcc-7/lib/gcc/sparc-sun-solaris2.10/7.1.0/include-fixed/curses.h:699:12: note: initializing argument 4 of âint mvwaddstr(WINDOW*, int, int, char*)â
> extern int mvwaddstr(WINDOW *, int, int, char *);
> ^~~~~~~~~
> make[2]: *** [Makefile:1927: tui-winsource.o] Error 1
>
> Unlike ncurses, <curses.h> declares
>
> extern int mvwaddstr(WINDOW *, int, int, char *);
>
> i.e. the last arg is char *, not const char *.
>
> The patch fixes this by casting the last arg to mvwaddstr to char *,
> as was recently done on mainline in a newterm() call (the only
> difference between 8.0 and mainline gdb/tui).
That's fine with me.
Looking at:
https://docs.oracle.com/cd/E19455-01/806-0629/6j9vjco9i/index.html
I see that this affects several APIs, so nicer would be to
fix this centrally in gdb_curses.h like we fix e.g.,
PyObject_GetAttrString in python/python-internal.h. But that can
be for another day.
>
> With those changes, gdb on the 8.0 branch compiles cleanly on
> sparcv9-sun-solaris2.10 with native curses and amd64-pc-solaris2.12
> with bundled ncurses (well, almost: on Solaris 12 ncurses in
> /usr/include is used, but gdb linked against -lcurses which fails:
>
> Undefined first referenced
> symbol in file
> wattr_on tui-wingeneral.o
> wattr_off tui-wingeneral.o
>
> but that's a different and preexisting problem).
These two problems would be better pushed as two separate patches
(with the rationales given above as separate commit logs).
> Ok for mainline and 8.0 branch?
The cast bits are OK. I'd like to hear your opinion on
moving the NOMACROS define to gdb_curses.h, before including
<curses.h>.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-05-18 13:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 8:56 Rainer Orth
2017-05-18 13:19 ` Pedro Alves [this message]
2017-05-18 13:36 ` Rainer Orth
2017-05-19 12:50 ` Rainer Orth
2017-05-19 12:52 ` Pedro Alves
2017-05-19 13:20 ` Eli Zaretskii
2017-05-19 13:26 ` Rainer Orth
2017-05-19 13:43 ` Pedro Alves
2017-05-19 13:39 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32521e83-00b5-e2a8-faff-03b5407cfc67@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=ro@CeBiTec.Uni-Bielefeld.DE \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox