Change in ncurses in devel?

[Miroslav Lichvar]

On Wed, Feb 21, 2007 at 10:30:01PM +0100, Gérard Milmeister wrote:
> I tried to rebuild ucblogo to use ncurses and not termcap, and got a
> link error specific to the ncurses in devel. 

Here is the error:

gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables   -I/usr/include -O0  coms.o error.o eval.o files.o graphics.o init.o intern.o libloc.o lists.o logodata.o main.o math.o mem.o paren.o parse.o print.o term.o wrksp.o xgraphics.o nographics.o -lSM -lICE  -L/usr/lib -lbsd -lm  -lcurses -lX11  -o logo
/usr/bin/ld: term.o(.debug_info+0xc0c): unresolvable R_386_32 relocation against symbol `ospeed'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

> I found out that I needed
> to link with cursesw instead of curses (support for wide characters).
> This is because "ncurses/ncurses.h" pulls in "ncursesw/ncurses_dll.h"
> instead of just "ncurses/ncurses_dll.h" as it does on FC6. 

ncursesw headers are compatible with ncurses headers, only ncursesw
headers are installed now.

> The ncursesw
> version adds a symbol "ospeed" absent from libcurses but present in
> libcursesw?

Symbol ospeed is in libtinfo and libncurse depend on this library, so
that shouldn't be the problem. libncursesw have it's own libtinfo included
as there is an issue that needs to be resolved before both libraries
can use the same libtinfo.

> Is this a bug, or is there a rationale behind?

ucblogo needs a bit of patching, term.c declares ospeed as short, but
it should be unsigned int.

-- 
Miroslav Lichvar