Bug#868609: le FTBFS with latest ncurses
X-Debbugs-CC: l...@netis.ru 在 2017年8月23日星期三 CST 下午10:27:46，您写道： > On 23 August 2017 at 14:56, Alexander V. Lukyanov wrote: > > On Fri, Aug 18, 2017 at 12:39:00PM +0200, Raphael Geissert wrote: > >> Do you plan to make a new release with the fixes? or should I grab the > >> patches from github? > > > > 1.16.5 has been released. > > Awesome, thanks. I'll take care of the upload. > > Cheers, Hi Raphael, I noticed that the new version of le with fix has been released for a while but no uploads have been made yet. Do you have spare time to fix this bug and upload a new version recently? Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#868609: le FTBFS with latest ncurses
On 23 August 2017 at 14:56, Alexander V. Lukyanov wrote: > On Fri, Aug 18, 2017 at 12:39:00PM +0200, Raphael Geissert wrote: >> Do you plan to make a new release with the fixes? or should I grab the >> patches from github? > > 1.16.5 has been released. Awesome, thanks. I'll take care of the upload. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net
Bug#868609: le FTBFS with latest ncurses
On Fri, Aug 18, 2017 at 12:39:00PM +0200, Raphael Geissert wrote: > Do you plan to make a new release with the fixes? or should I grab the > patches from github? 1.16.5 has been released. -- Alexander.
Bug#868609: le FTBFS with latest ncurses
On Fri, Aug 18, 2017 at 12:39:00PM +0200, Raphael Geissert wrote: > Do you plan to make a new release with the fixes? or should I grab the > patches from github? I'm going to release next version soon. I'm only waiting for a feedback from a NetBSD user (compilation problem). -- Alexander.
Bug#868609: le FTBFS with latest ncurses
Alexander, Do you plan to make a new release with the fixes? or should I grab the patches from github? I'd like to fix this some time soon to get le back in testing. Thanks in advance. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net
Bug#868609: le FTBFS with latest ncurses
On Wed, Jul 26, 2017 at 05:18:57AM -0400, Thomas Dickey wrote:
> On Tue, Jul 25, 2017 at 01:19:16PM +0300, Alexander V. Lukyanov wrote:
> > On Tue, Jul 25, 2017 at 04:55:54AM -0400, Thomas Dickey wrote:
> > > > > e) fix a different fail-to-build with the opaque TERMTYPE
> > > >
> > > > I don't see how these lines are equivalent:
> > > >
> > > > - TERMTYPE *tp = &cur_term->type;
> > > > + TERMTYPE *tp = (TERMTYPE *)(&cur_term);
> > >
> > > They're the same because the first member of TERMINAL happens to be
> > > a TERMTYPE, and since TERMINAL is opaque in current code (so you
> > > cannot refer to the "type" member any longer).
> >
> > But shouln't it be (TERMTYPE *)(cur_term) ?
>
> hmm - I agree that doesn't look right (the problem with casts).
> I'm surprised it worked.
attaching an improved patch (with some additional compiler-warning fixes)
sadly enough, either way the cast gives no warnings, and the program
appears to run.
also attaching a copy of valgrind log from running the program with
the _nc_free_and_exit function turned on (just from opening a file,
looking at some menus and quitting - ymmv).
> > Is there a new function or macro to get current TERMTYPE, so that I could
> > use it if available?
>
> Not syntactically the same. This is what I use in term.h:
>
> /* The cast works because TERMTYPE is the first data in TERMINAL */
> #define CUR ((TERMTYPE *)(cur_term))->
I'm reluctant to add a new function for accessing things that "should"
just work: the definitions in term.h are the defined interface, and
providing a function to access those in a different way doesn't seem
a good solution.
Of course, if that structure hadn't happened to be first in TERMINAL,
I'd have had to provide a function, just to keep TERMINAL opaque.
Since I'm keeping binary compatibility (aside from preventing applications
from knowing how large TERMINAL is), it's good enough for now.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
# ftp://invisible-island.net/temp/le-1.16.3-fix2.patch.gz
# patch by Thomas E. Dickey
# created Sun Jul 30 21:45:33 UTC 2017
# --
# color.cc |6 +++---
# edit.cc | 26 ++
# keymap.cc|4 ++--
# keynames.cc |2 +-
# make-mainmenu.pl |2 +-
# regex.c | 10 --
# 6 files changed, 33 insertions(+), 17 deletions(-)
# --
Index: src/color.cc
--- le-1.16.3/src/color.cc 2013-03-18 13:44:31.0 +
+++ le-1.16.3-fix2/src/color.cc 2017-07-22 12:42:26.0 +
@@ -33,7 +33,7 @@
int can_use_default_colors;
int next_pair;
-static int find_pair(int fg,int bg)
+static int find_or_init_pair(int fg,int bg)
{
if(!can_use_default_colors)
{
@@ -67,7 +67,7 @@
attr_table[an].n_attr=0;
if(pal[i].fg!=NO_COLOR || pal[i].bg!=NO_COLOR)
{
- pair=find_pair(pal[i].fg,pal[i].bg);
+ pair=find_or_init_pair(pal[i].fg,pal[i].bg);
attr_table[an].n_attr|=COLOR_PAIR(pair);
}
attr_table[an].n_attr|=pal[i].attr;
@@ -94,7 +94,7 @@
else
{
attr_table[i].so_attr=(attr_table[i].n_attr|hl->attr)&~A_COLOR;
- pair=find_pair(hl->fg,pal[p].bg);
+ pair=find_or_init_pair(hl->fg,pal[p].bg);
attr_table[i].so_attr|=COLOR_PAIR(pair);
}
}
Index: src/edit.cc
--- le-1.16.3/src/edit.cc 2015-12-03 07:15:40.0 +
+++ le-1.16.3-fix2/src/edit.cc 2017-07-22 13:15:35.0 +
@@ -53,6 +53,15 @@
# define fcntl(x,y,z) (0)
#endif
+#ifdef HAVE__NC_FREE_AND_EXIT
+extern "C" {
+extern void _nc_free_and_exit(int);
+#define ExitProgram(code) _nc_free_and_exit(code)
+};
+#else
+#define ExitProgram(code) exit(code)
+#endif
+
#include
#include "localcharset.h"
@@ -385,7 +394,7 @@
if(le_scr==NULL)
{
fprintf(stderr,"le: newterm() failed. Check your $TERM variable.\n");
- exit(1);
+ ExitProgram(1);
}
#endif
@@ -529,7 +538,7 @@
TermCurses();
- exit(0);
+ ExitProgram(0);
}
void PrintUsage(int arg)
@@ -557,7 +566,7 @@
"\n"
"The last file will be loaded. If no files specified, last readable file\n"
"from history will be loaded if the path is relative or it is the last.\n");
- exit(1);
+ ExitProgram(1);
}
#if USE_MULTIBYTE_CHARS
@@ -680,19 +689,19 @@
break;
case('?'):
fprintf(stderr,"%s: Try `%s --help' for more information\n",Program,argv[0]);
- exit(1);
+ ExitProgram(1);
case(DUMP_KEYMAP):
WriteActionMap(stdout);
- exit(0);
+ ExitProgram(0);
case(DUMP_COLORS):
DumpDefaultColors(stdout);
- exit(0);
+ ExitProgram(0);
case(PRINT_HELP):
PrintUsage(0);
- exit(0);
+ ExitProgram(0);
case(PRINT_VERSION):
PrintVersion();
- exit(0);
+ ExitProgram(0);
case(USE_MMAP):
opt_use_mmap=1;
if(optView==-1)
@@ -793,5 +802,6 @@
}
Edit();
Bug#868609: le FTBFS with latest ncurses
On Tue, Jul 25, 2017 at 01:19:16PM +0300, Alexander V. Lukyanov wrote: > On Tue, Jul 25, 2017 at 04:55:54AM -0400, Thomas Dickey wrote: > > > > e) fix a different fail-to-build with the opaque TERMTYPE > > > > > > I don't see how these lines are equivalent: > > > > > > - TERMTYPE *tp = &cur_term->type; > > > + TERMTYPE *tp = (TERMTYPE *)(&cur_term); > > > > They're the same because the first member of TERMINAL happens to be > > a TERMTYPE, and since TERMINAL is opaque in current code (so you > > cannot refer to the "type" member any longer). > > But shouln't it be (TERMTYPE *)(cur_term) ? hmm - I agree that doesn't look right (the problem with casts). I'm surprised it worked. > Is there a new function or macro to get current TERMTYPE, so that I could > use it if available? Not syntactically the same. This is what I use in term.h: /* The cast works because TERMTYPE is the first data in TERMINAL */ #define CUR ((TERMTYPE *)(cur_term))-> -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#868609: le FTBFS with latest ncurses
On Tue, Jul 25, 2017 at 04:55:54AM -0400, Thomas Dickey wrote: > > > e) fix a different fail-to-build with the opaque TERMTYPE > > > > I don't see how these lines are equivalent: > > > > - TERMTYPE *tp = &cur_term->type; > > + TERMTYPE *tp = (TERMTYPE *)(&cur_term); > > They're the same because the first member of TERMINAL happens to be > a TERMTYPE, and since TERMINAL is opaque in current code (so you > cannot refer to the "type" member any longer). But shouln't it be (TERMTYPE *)(cur_term) ? Is there a new function or macro to get current TERMTYPE, so that I could use it if available? -- Alexander.
Bug#868609: le FTBFS with latest ncurses
On Tue, Jul 25, 2017 at 10:04:02AM +0300, Alexander V. Lukyanov wrote: > On Sat, Jul 22, 2017 at 10:52:19AM -0400, Thomas Dickey wrote: > > c) add a cast to fix a signed/unsigned compiler warning > > I will check if a newer/better version of regex.c if available in emacs (it > was taken from there). > > > d) add (to help with running valgrind) the ExitProgram macro > > Where is HAVE__NC_FREE_AND_EXIT defined? It would be defined if you had (an optional) configure check for _nc_free_and_exit. I do this for example when debugging ncurses applications and want to check for memory leaks. But see http://invisible-island.net/ncurses/ncurses.faq.html#config_leaks > > e) fix a different fail-to-build with the opaque TERMTYPE > > I don't see how these lines are equivalent: > > - TERMTYPE *tp = &cur_term->type; > + TERMTYPE *tp = (TERMTYPE *)(&cur_term); They're the same because the first member of TERMINAL happens to be a TERMTYPE, and since TERMINAL is opaque in current code (so you cannot refer to the "type" member any longer). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#868609: le FTBFS with latest ncurses
On Sat, Jul 22, 2017 at 10:52:19AM -0400, Thomas Dickey wrote: > c) add a cast to fix a signed/unsigned compiler warning I will check if a newer/better version of regex.c if available in emacs (it was taken from there). > d) add (to help with running valgrind) the ExitProgram macro Where is HAVE__NC_FREE_AND_EXIT defined? > e) fix a different fail-to-build with the opaque TERMTYPE I don't see how these lines are equivalent: - TERMTYPE *tp = &cur_term->type; + TERMTYPE *tp = (TERMTYPE *)(&cur_term); Can you elaborate? -- Alexander.
Bug#868609: le FTBFS with latest ncurses
To ensure that I made a correct fix, I test-compiled le-1.16.3 and ran it.
Doing that, I noticed some additional issues (partly because I did not
override the makefile's C++ variables, but that was just as well, since
it prompted me to do the extra fixes):
a) renamed the private symbol find_pair to find_or_init_pair
b) include unistd.h to get prototype for write()
c) add a cast to fix a signed/unsigned compiler warning
d) add (to help with running valgrind) the ExitProgram macro
e) fix a different fail-to-build with the opaque TERMTYPE
Having done that, in a quick check the menus came up, and valgrind
had only reported an issue with linux_process_key() which I suppose
Alexander is familiar with.
There are still more than a hundred compiler warnings.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
# patch by Thomas E. Dickey
# created Sat Jul 22 14:39:46 UTC 2017
# --
# color.cc|6 +++---
# edit.cc | 26 ++
# keynames.cc |2 +-
# regex.c |8 ++--
# 4 files changed, 28 insertions(+), 14 deletions(-)
# --
Index: src/color.cc
--- le-1.16.3/src/color.cc 2013-03-18 13:44:31.0 +
+++ le-1.16.3-fix/src/color.cc 2017-07-22 12:42:26.382956801 +
@@ -33,7 +33,7 @@
int can_use_default_colors;
int next_pair;
-static int find_pair(int fg,int bg)
+static int find_or_init_pair(int fg,int bg)
{
if(!can_use_default_colors)
{
@@ -67,7 +67,7 @@
attr_table[an].n_attr=0;
if(pal[i].fg!=NO_COLOR || pal[i].bg!=NO_COLOR)
{
- pair=find_pair(pal[i].fg,pal[i].bg);
+ pair=find_or_init_pair(pal[i].fg,pal[i].bg);
attr_table[an].n_attr|=COLOR_PAIR(pair);
}
attr_table[an].n_attr|=pal[i].attr;
@@ -94,7 +94,7 @@
else
{
attr_table[i].so_attr=(attr_table[i].n_attr|hl->attr)&~A_COLOR;
- pair=find_pair(hl->fg,pal[p].bg);
+ pair=find_or_init_pair(hl->fg,pal[p].bg);
attr_table[i].so_attr|=COLOR_PAIR(pair);
}
}
Index: src/edit.cc
--- le-1.16.3/src/edit.cc 2015-12-03 07:15:40.0 +
+++ le-1.16.3-fix/src/edit.cc 2017-07-22 13:15:35.326113146 +
@@ -53,6 +53,15 @@
# define fcntl(x,y,z) (0)
#endif
+#ifdef HAVE__NC_FREE_AND_EXIT
+extern "C" {
+extern void _nc_free_and_exit(int);
+#define ExitProgram(code) _nc_free_and_exit(code)
+};
+#else
+#define ExitProgram(code) exit(code)
+#endif
+
#include
#include "localcharset.h"
@@ -385,7 +394,7 @@
if(le_scr==NULL)
{
fprintf(stderr,"le: newterm() failed. Check your $TERM variable.\n");
- exit(1);
+ ExitProgram(1);
}
#endif
@@ -529,7 +538,7 @@
TermCurses();
- exit(0);
+ ExitProgram(0);
}
void PrintUsage(int arg)
@@ -557,7 +566,7 @@
"\n"
"The last file will be loaded. If no files specified, last readable file\n"
"from history will be loaded if the path is relative or it is the last.\n");
- exit(1);
+ ExitProgram(1);
}
#if USE_MULTIBYTE_CHARS
@@ -680,19 +689,19 @@
break;
case('?'):
fprintf(stderr,"%s: Try `%s --help' for more information\n",Program,argv[0]);
- exit(1);
+ ExitProgram(1);
case(DUMP_KEYMAP):
WriteActionMap(stdout);
- exit(0);
+ ExitProgram(0);
case(DUMP_COLORS):
DumpDefaultColors(stdout);
- exit(0);
+ ExitProgram(0);
case(PRINT_HELP):
PrintUsage(0);
- exit(0);
+ ExitProgram(0);
case(PRINT_VERSION):
PrintVersion();
- exit(0);
+ ExitProgram(0);
case(USE_MMAP):
opt_use_mmap=1;
if(optView==-1)
@@ -793,5 +802,6 @@
}
Edit();
Terminate();
+ ExitProgram(0);
return 0;
}
Index: src/keynames.cc
--- le-1.16.3/src/keynames.cc 2013-03-18 13:44:31.0 +
+++ le-1.16.3-fix/src/keynames.cc 2017-07-22 14:37:00.829660294 +
@@ -353,7 +353,7 @@
if(!cur_term)
return;
- TERMTYPE *tp = &cur_term->type;
+ TERMTYPE *tp = (TERMTYPE *)(&cur_term);
if(!tp)
return;
if(NUM_STRINGS(tp)<=STRCOUNT)
Index: src/regex.c
--- le-1.16.3/src/regex.c 2013-03-18 13:44:31.0 +
+++ le-1.16.3-fix/src/regex.c 2017-07-22 12:52:29.475732342 +
@@ -202,6 +202,10 @@
char *realloc ();
# endif
+#ifdef HAVE_UNISTD_H
+#include
+#endif
+
/* When used in Emacs's lib-src, we need xmalloc and xrealloc. */
void *
@@ -2152,7 +2156,7 @@
re_wctype (str)
re_char *str;
{
- const char *string = str;
+ const char *string = (const char *)str;
if (STREQ (string, "alnum")) return RECC_ALNUM;
else if (STREQ (string, "alpha")) return RECC_ALPHA;
else if (STREQ (string, "word")) return RECC_WORD;
@@ -2742,7 +2746,7 @@
main_pend = pend;
main_pattern = pattern;
p = pattern = whitespace_regexp;
- pend = p + strlen (p);
+ pend = p + strlen ((const char *) p);
break;
}
signature.asc
Description: Digital signature
Bug#868609: le FTBFS with latest ncurses
On Mon, Jul 17, 2017 at 02:51:22PM +0300, Alexander V. Lukyanov wrote: > On Mon, Jul 17, 2017 at 05:28:09AM -0400, Thomas Dickey wrote: > > On Mon, Jul 17, 2017 at 11:43:35AM +0300, Alexander V. Lukyanov wrote: > > > On Mon, Jul 17, 2017 at 02:48:27AM +0300, Adrian Bunk wrote: > > > > Source: le > > > > Version: 1.16.3-1 > > > > Severity: serious > > > > Tags: buster sid > > > > > > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html This is a problem with "le". I'm reassigning to that program, along with a patch to fix the issues I found. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#868609: le FTBFS with latest ncurses
On Mon, Jul 17, 2017 at 05:28:09AM -0400, Thomas Dickey wrote: > On Mon, Jul 17, 2017 at 11:43:35AM +0300, Alexander V. Lukyanov wrote: > > On Mon, Jul 17, 2017 at 02:48:27AM +0300, Adrian Bunk wrote: > > > Source: le > > > Version: 1.16.3-1 > > > Severity: serious > > > Tags: buster sid > > > > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html > > > > > > ... > > > gcc -DHAVE_CONFIG_H -I. -I../lib -I../lib -I../lib > > > -I/usr/include/ncursesw -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > > > -fstack-protector-strong -Wformat -Werror=format-security -Wall > > > -Wwrite-strings -Woverloaded-virtual -fno-exceptions -fno-rtti > > > -fno-implement-inlines -c -o color.o color.cc > > > color.cc: In function 'int find_pair(int, int)': > > > color.cc:36:12: error: 'int find_pair(int, int)' was declared 'extern' > > > and later 'static' [-fpermissive] > > > static int find_pair(int fg,int bg) > > > ^ > > > In file included from edit.h:36:0, > > > from color.cc:27: > > > /usr/include/ncursesw/curses.h:924:28: note: previous declaration of 'int > > > find_pair(int, int)' > > > extern NCURSES_EXPORT(int) find_pair (int, int); > > > ^ > > > Makefile:1299: recipe for target 'color.o' failed > > > make[3]: *** [color.o] Error 1 > > > > ncurses was extended with new symbols, some of which conflict with "le" > > internal names. So either ncurses should be fixed not to export these > > symbols by default or le should be fixed to rename its identifiers. > > hmm - not that I'm oblivious to the problem, but (for example) a quick > check on an alternate name "find_color_pair" finds existing usage too. > This problem will come up since there's no namespaces in C (not that > C++ is free from the problem). > > So... I could look for a rarely-used name (which still gives the same > connotations), or the couple of applications using ncurses could be > modified. What about a separate include file for curses extensions, somthing like ncurses_ext.h? This way any new identifiers won't conflict with legacy code. Other common way to avoid conflicts is prefixing the identifiers. nc_find_pair is much less likely to conflict. -- Alexander.
Bug#868609: le FTBFS with latest ncurses
On Mon, Jul 17, 2017 at 11:43:35AM +0300, Alexander V. Lukyanov wrote: > On Mon, Jul 17, 2017 at 02:48:27AM +0300, Adrian Bunk wrote: > > Source: le > > Version: 1.16.3-1 > > Severity: serious > > Tags: buster sid > > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html > > > > ... > > gcc -DHAVE_CONFIG_H -I. -I../lib -I../lib -I../lib -I/usr/include/ncursesw > > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat > > -Werror=format-security -Wall -Wwrite-strings -Woverloaded-virtual > > -fno-exceptions -fno-rtti -fno-implement-inlines -c -o color.o color.cc > > color.cc: In function 'int find_pair(int, int)': > > color.cc:36:12: error: 'int find_pair(int, int)' was declared 'extern' and > > later 'static' [-fpermissive] > > static int find_pair(int fg,int bg) > > ^ > > In file included from edit.h:36:0, > > from color.cc:27: > > /usr/include/ncursesw/curses.h:924:28: note: previous declaration of 'int > > find_pair(int, int)' > > extern NCURSES_EXPORT(int) find_pair (int, int); > > ^ > > Makefile:1299: recipe for target 'color.o' failed > > make[3]: *** [color.o] Error 1 > > ncurses was extended with new symbols, some of which conflict with "le" > internal names. So either ncurses should be fixed not to export these > symbols by default or le should be fixed to rename its identifiers. hmm - not that I'm oblivious to the problem, but (for example) a quick check on an alternate name "find_color_pair" finds existing usage too. This problem will come up since there's no namespaces in C (not that C++ is free from the problem). So... I could look for a rarely-used name (which still gives the same connotations), or the couple of applications using ncurses could be modified. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#868609: le FTBFS with latest ncurses
On Mon, Jul 17, 2017 at 02:48:27AM +0300, Adrian Bunk wrote: > Source: le > Version: 1.16.3-1 > Severity: serious > Tags: buster sid > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html > > ... > gcc -DHAVE_CONFIG_H -I. -I../lib -I../lib -I../lib -I/usr/include/ncursesw > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -Wall -Wwrite-strings -Woverloaded-virtual > -fno-exceptions -fno-rtti -fno-implement-inlines -c -o color.o color.cc > color.cc: In function 'int find_pair(int, int)': > color.cc:36:12: error: 'int find_pair(int, int)' was declared 'extern' and > later 'static' [-fpermissive] > static int find_pair(int fg,int bg) > ^ > In file included from edit.h:36:0, > from color.cc:27: > /usr/include/ncursesw/curses.h:924:28: note: previous declaration of 'int > find_pair(int, int)' > extern NCURSES_EXPORT(int) find_pair (int, int); > ^ > Makefile:1299: recipe for target 'color.o' failed > make[3]: *** [color.o] Error 1 ncurses was extended with new symbols, some of which conflict with "le" internal names. So either ncurses should be fixed not to export these symbols by default or le should be fixed to rename its identifiers. -- Alexander.
Bug#868609: le FTBFS with latest ncurses
Source: le Version: 1.16.3-1 Severity: serious Tags: buster sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html ... gcc -DHAVE_CONFIG_H -I. -I../lib -I../lib -I../lib -I/usr/include/ncursesw -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wwrite-strings -Woverloaded-virtual -fno-exceptions -fno-rtti -fno-implement-inlines -c -o color.o color.cc color.cc: In function 'int find_pair(int, int)': color.cc:36:12: error: 'int find_pair(int, int)' was declared 'extern' and later 'static' [-fpermissive] static int find_pair(int fg,int bg) ^ In file included from edit.h:36:0, from color.cc:27: /usr/include/ncursesw/curses.h:924:28: note: previous declaration of 'int find_pair(int, int)' extern NCURSES_EXPORT(int) find_pair (int, int); ^ Makefile:1299: recipe for target 'color.o' failed make[3]: *** [color.o] Error 1
