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
>
> 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
> > 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?
>
> 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.


Cordially,

Perry