Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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