[Top][All Lists]

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

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

From: amores perros
Subject: Re: I've made a simple program, showing UTF-8 lower but not uppercase working
Date: Sat, 24 Sep 2005 16:07:26 +0000

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

On Fri, 23 Sep 2005, amores perros wrote:

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.

I guess it's complicated to explain without an example...

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.

A packager could use the headers from libncursesw with libncurses,
since the places where curses.h differ are ifdef'd with _XOPEN_SOURCE_EXTENDED

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

That's the simplest solution.

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?

But that wouldn't work, since libncurses doesn't handle UTF-8.
It's rather unlikely that an old system would have a new version of
libncurses which was contrived to make Latin-1 work in a UTF-8 locale.

Oh, but, I've heard from a couple of people that they just avoid
using UTF-8 locales because of this problem, so a binary linked to
libncurses would continue to work for people not using UTF-8
locales as before (and still not work with UTF-8 locales of course).
That's what I meant.

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

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?

Sure - configure ncurses to produce static libraries and link your
application against that, using the -L option to specify the directory containing the static libraries. That generally works on Linux, but not necessarily on other systems.

no problem

So the packager making a binary distribution, who wants to
make a statically linked binary, needs to have
ncurses static libraries, or else to get a source version of
ncurses and configure it himself (herself) to produce static
libraries. And I'd need to provide some type of switch
in configure.in so that the configure had a switch to pass
through the -L parameter -- at least for the latter case; in
the former case, if the packager has static libraries in some
default location, perhaps I wouldn't need the -L option?

But, I'm now aware that debian stable and Fink both have
libncursesw available, so requiring that seems now reasonable
to me.



reply via email to

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