bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NCURSES_CH_T definition and ncurses.h in toolchain sys-root include path


From: Florian Fainelli
Subject: NCURSES_CH_T definition and ncurses.h in toolchain sys-root include path
Date: Tue, 13 Sep 2016 17:31:14 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Hi all,

While debugging the following build failure encountered with building
libncursesw:

arm-linux-gnueabihf-gcc -DHAVE_CONFIG_H -I../ncurses -I.
-I/exp00/fainelli/openwrt/trunk/staging_dir/target-arm-linux-gnueabihf/usr/include
-I/exp00/fainelli/openwrt/trunk/staging_dir/target-arm-linux-gnueabihf/include
-I/opt/toolchains/stbgcc-4.8-1.5//usr/include
-I/opt/toolchains/stbgcc-4.8-1.5//include  -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64  -DNDEBUG -I. -I../include -Os -pipe
-march=armv7-a -mtune=cortex-a15 -fno-caller-saves -mfloat-abi=hard
-fpic   --param max-inline-insns-single=1200 -fPIC -c
../ncurses/./tty/hashmap.c -o ../obj_s/hashmap.o
../ncurses/./tty/hashmap.c:115:1: warning: braces around scalar
initializer [enabled by default]
 static const NCURSES_CH_T blankchar = NewChar(BLANK_TEXT);
 ^
../ncurses/./tty/hashmap.c:115:1: warning: (near initialization for
'blankchar') [enabled by default]
../ncurses/./tty/hashmap.c:115:1: warning: excess elements in scalar
initializer [enabled by default]
../ncurses/./tty/hashmap.c:115:1: warning: (near initialization for
'blankchar') [enabled by default]
../ncurses/./tty/hashmap.c:115:1: warning: excess elements in scalar
initializer [enabled by default]
../ncurses/./tty/hashmap.c:115:1: warning: (near initialization for
'blankchar') [enabled by default]
../ncurses/./tty/hashmap.c:115:1: warning: excess elements in scalar
initializer [enabled by default]
../ncurses/./tty/hashmap.c:115:1: warning: (near initialization for
'blankchar') [enabled by default]
../ncurses/./tty/hashmap.c:115:1: warning: excess elements in scalar
initializer [enabled by default]
../ncurses/./tty/hashmap.c:115:1: warning: (near initialization for
'blankchar') [enabled by default]
../ncurses/./tty/hashmap.c:115:1: warning: excess elements in scalar
initializer [enabled by default]
../ncurses/./tty/hashmap.c:115:1: warning: (near initialization for
'blankchar') [enabled by default]
../ncurses/./tty/hashmap.c: In function 'hash':
../ncurses/./tty/hashmap.c:110:25: error: request for member 'chars' in
something not a structure or union
 #define HASH_VAL(ch) (ch.chars[0])

after looking a bit at the pre-processor file, hashmap.i shows that
NCURSES_CH_T is defined as a chtype, which is an unsigned long, yet,
hashmap.c has USE_WIDEC_SUPPORT enabled so we end-up with this being used:

#define HASH_VAL(ch) (ch.chars[0])

which is indeed not a structure but just a scalar type. This toolchain
actually has ncurses.h available in its sys-root folder, which is
consequently searched:

color_t;
# 288 "../ncurses/curses.priv.h"
# 1
"/exp00/fainelli/openwrt/trunk/staging_dir/target-arm-linux-gnueabihf/usr/include/curses.h"
1
# 143
"/exp00/fainelli/openwrt/trunk/staging_dir/target-arm-linux-gnueabihf/usr/include/curses.h"
typedef unsigned long chtype;
typedef unsigned long mmask_t;

and therefore modifies how NCURSES_CH_T is defined for all the functions
defined in hashmap.c, whereas in the working case, where we do not
necessarily have ncurses.h searched:

color_t;
# 288 "../ncurses/curses.priv.h"
# 1 "../include/curses.h" 1
# 143 "../include/curses.h"
typedef unsigned long chtype;
typedef unsigned long mmask_t;

We end-up with the correct definition of this type for these functions
which is cchar_t.

Now, a quirk and dirty fix is this:

#include "../include/curses.h"
#include <curses.priv.h>

but I really don't think this is what was envisioned, rather it seems
like we would entirely prevent the inclusion of any kind of external
ncurses.h file, but if we use -nostdinc, that's a little too heavy
weighted for what curses.priv.h may need.

Any suggestions on how to best solve this (yes, fixing the toolchain not
to have the header is kind of the way forward).

Thanks!
-- 
Florian



reply via email to

[Prev in Thread] Current Thread [Next in Thread]