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

Bug#634200: marked as done (gcc -Wall -Werror -lncurses fails to link wide-character ncursesw functions.)



Your message dated Mon, 18 Jul 2011 19:14:25 +0200
with message-id <4E2469F1.8020603@debian.org>
and subject line Re: Bug#634200: #634200 gcc -Wall -Werror -lncurses fails to link wide-character ncursesw functions.
has caused the Debian Bug report #634200,
regarding gcc -Wall -Werror -lncurses fails to link wide-character ncursesw functions.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
634200: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634200
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: gcc
Version: 4:4.4.5-1
Severity: normal
Tags: l10n

In reply to your
Fwd: Message with no Package: tag cannot be processed!(...)

(reportbug fails on my system due to sendmail not being installed.
 Like most sane people I use Qmail.  should I file a bug against
 reportbug?)
----original message---
I'm reporting this bug against GCC (current version installed is
4:4.4.5-1)

This is an internationalization bug.

This is "Normal" priority (priority 6).

There is a workaround: never use -Wall or -Werror on the same gcc
command line with -lncursesw or to link files that #include <wctype.h> .


My usual build options are "gcc -Wall -Werror ..."  In attempting to
link an ncursesw package I found that the wide-character functions in
ncursesw were not linkable.  In trying ever-more-trival cases to try
to figure it out, I eventually (accidentally) built straight from
the command line, leaving out the build options, and a call to a
wide-character function linked.  After some confusion, I realized that
the relevant difference was the absence of my usual build options
rather than whatever-it-was that I was testing.  Taking the build
options out of my makefile allowed the main project I was working on
to build.  Experimentation reveals that either of these build options
(-Wall or -Werror) is sufficient to prevent linking.

The bug against gcc is that regardless of the extreme macrology in
/lib/include/ncursesw/ncurses.h and /lib/include/wctype.h these
build options ought not affect the linker's view of available
functions.

Affected functions include basically everything which uses the wide
character type defined in wctype.h or the functions defined on ints
in ctype.h. These functions include, but are probably not limited to,

in_wch,  mvin_wch, mvwin_wch, win_wch, get_wch,  wget_wch,  mvget_wch,
mvwget_wch,  unget_wch, get_wstr, getn_wstr, wget_wstr, wgetn_wstr,
mvget_wstr, mvgetn_wstr, mvwget_wstr, mvwgetn_wstr,get_wstr, getn_wstr,
wget_wstr, wgetn_wstr, mvget_wstr, mvgetn_wstr, mvwget_wstr,
mvwgetn_wstr, ins_wch, mvins_wch, mvwins_wch, wins_wch, iswgraph,
isgraph, iswspace, isspace, iswalnum, isalnum, iswctype, etc.

example of the error:

bear@janus:~/src/xxh$make display.o
make display.o
gcc -Wall -Werror -lncursesw -c -o display.o display.c
cc1: warnings being treated as errors
display.c: In function ‘Disp_GetKey’:
display.c:183: error: implicit declaration of function ‘get_wch’
display.c: In function ‘Disp_GetKeynames’:
display.c:334: error: implicit declaration of function ‘iswgraph’
display.c: In function ‘Disp_Say’:
display.c:1333: error: implicit declaration of function ‘iswspace’
..........etc........
make: *** [display.o] Error 1
bear@janus:~/src/xxh$


display.c starts with the lines:


#define _X_OPEN_SOURCE_EXTENDED

/* stdlib for qsort */
#include <stdlib.h>
/* wchar for wint_t type */
#include <wchar.h>
/* wide ncurses for display and input handling */
#include <ncursesw/curses.h>
/* malloc for calloc and free */
#include <malloc.h>
/* string.h for memcpy */
#include <string.h>
#include <assert.h>


......etc.......




				Ray "Bear" Dillinger

My system: AMD64, dual-core, prefer 'stable' release, up-to-date as of
July 16 2011.




--- End Message ---
--- Begin Message ---
On 07/18/2011 04:39 PM, Ray Dillinger wrote:
>>> bear@janus:~/src/xxh$ make display.o
>>> gcc -D_XOPEN_SOURCE_EXTENDED -Wall -Werror -lncursesw -c -o display.o \
>>> display.c
>>> bear@janus:~/src/xxh$
> 
>> should't the ncursesw headers be used?
> 
> Sorry, don't understand your message. The ncursesw header is invoked
> by the -lncursesw compile line option above,

??? linking a library doesn't say anything about the include path.

> *and* by #include
> <ncursesw/curses.h> in the file itself; isn't that enough?!

no.

>> pkg-config --cflags ncursesw
> 
> Can't use pkg-config on this project; it must be compilable on
> machines that don't have it installed.

then use Tom's suggestion.

I'm closing the bug report now.


--- End Message ---

Reply to: