Re: I've made a simple program, showing UTF-8 lower but not uppercase working

[amores perros]

> From: Thomas Dickey To: amores perros CC: mailing list
> Subject: Re: I've made a simple program, showing UTF-8 lower but not 
> uppercase working
> Date: Fri, 23 Sep 2005 19:24:57 -0400 (EDT)

<snip>

> > I'm sorry to belabor this, but since I'm unsure, is there any way I can
> > make my program work on systems which have stock ncurses 5.4 installed
> > (as I gather many Debian systems, and perhaps others, will have)?
>
> no.  If you're running in UTF-8, there should be a corresponding 
> libncursesw available (whether or not it's installed).  I see that a 
> package for stable is available by looking here:
>
> http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=libncursesw5
>
> I note there that "oldstable" is pre-UTF-8 both for ncurses and for the
> system as a whole.
>
> > Or will I have to say, you cannot use UTF-8 unless you upgrade your
> > system by installing a widechar-compiled version of ncurses?
>
> That's essentially true.  Offhand I don't see a general use for the 
> workaround (in ncurses).  For vile it's useful since I'm more likely to be 
> editing Latin-1 text (for special things such as the copyright symbol) than 
> UTF-8.
>
> It would be useful for the legacy stuff that doesn't have any locale 
> support, but I've only seen comments about a couple of _those_ in the past 
> few weeks (not on Debian though).  Since it would rely on the application 
> setting up its locale properly, it would mean that the application has been 
> updated - in which case there's little reason for not also rebuilding 
> against ncursesw.

I'm not sure I follow the end.

Now I understand that libncursesw is only the dll, and is available
for debian stable, and endusers of a binary distribution only need that.

Developers will need libncursesw-dev, to have the headers at least.

I think I'm happy enough with this -- I can adjust my system so I
can compile and link to ncursesw.

Whoever packages a binary distribution, will have to choose to
build either with ncurses (usable by everyone) or with
ncursesw (slightly restricted audience, but supports UTF-8).

However, re:

> there's little reason for not also rebuilding against ncursesw.

The reason for not rebuilding against ncursesw would be if the
distributor wanted to distribute a binary which worked on systems
without libncursesw?


I suppose the way for everyone to have & eat cake, would
be for the distributor to make both versions, with slightly
different names (one linking to libncurses, and one linking to
libncursesw).

Or is it possible to compile & distribute a binary which links
only statically to libncursesw, and which therefore does not
require any libncursesw dll (libncursesw.so I assume) on the
enduser system?



> > In the meantime, I've gotten the ncurses5.4 source from a
> > gnu ftp site, and tried compiling it locally with --with-widechar,
>
>         --enable-widec

After compiling I couldn't find the header, so I did a make install
(I had used a local prefix in configure, as I wasn't working as root),
and I found that _XOPEN_SOURCE_EXTENDED was still
defined to 0 in my header -- Probably because "--with-widechar"
did nothing for me, being the wrong syntax -- thanks for
giving the right one -- I obviously was not paying careful enough
attention in the README. :)


> For casual testing in the build tree, I do
>
>         configure \
>                 --with-shared \
>                 --without-normal \
>                 --without-debug \
>                 --with-trace \
>                 --enable-widec
>
> > (as I suspect that I need that to get cchar_t defined)
>
> yes, and the application must define _XOPEN_SOURCE_EXTENDED

So when I get this right, I'll expect to no longer see
"#define _XOPEN_SOURCE_EXTENDED 0" in the generated curses.h.


Thanks for all the help.

Some of my problems have been due to a lot of ignorance on
my part, and thank you for for your patience.

Cordially,

Perry