Re: Bug#868609: le FTBFS with latest ncurses

[Alexander V. Lukyanov]

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.