Discussion:
Bug#868609: le FTBFS with latest ncurses
Add Reply
Alexander V. Lukyanov
2017-07-17 09:00:03 UTC
Reply
Permalink
Raw Message
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: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,
/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.
Thomas Dickey
2017-07-17 09:40:01 UTC
Reply
Permalink
Raw Message
Post by Alexander V. Lukyanov
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: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,
/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 <***@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
Thomas Dickey
2017-07-22 14:50:02 UTC
Reply
Permalink
Raw Message
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 <***@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
Thomas Dickey
2017-07-22 15:00:01 UTC
Reply
Permalink
Raw Message
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 <***@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
Loading...