This is the old SliTaz forum - Please use the main

Insufficient UTF-8 support was detected in your curses and/or C libraries
  • LuXLuX February 2010
    Hello !

    UTF-8 support is not fully achieved in Slitaz-Cooking. Among other things nano, contrary to less or vim-tiny, don't support UTF-8 in Slitaz, while it supports it pretty well in other distros. In order to understand this, I have tried to compile it from this source. Running ./configure produces the following message. The next steps "make && make install" run without problem, but the resulting program /usr/local/bin/nano doesn't support UTF-8, exactly as /usr/bin/nano. Very probably this message means that nano's compile option 'enable_utf8' is turned off due to this problem.
    configure:10684: WARNING:
    *** Insufficient UTF-8 support was detected in your curses and/or C
    *** libraries. If you want UTF-8 support, please verify that your slang
    *** was built with UTF-8 support or your curses was built with wide
    *** character support, and that your C library was built with wide
    *** character support.

    I have no idea how to do such verifications, but it would be nice if someone could do it. Hopefully, it may help solving other UTF-8 issues for Slitaz.

    Hope this helps,
  • GokhlayehGokhlayeh February 2010
    Hello LuX,
    As you know I don't use a UTF-8 system at this moment so I can't verify myself if my nano UTF-8 compliant is really UTF-8 compliant :)
    But I've found a solution at your problem.

    Some search learn me that we can compile ncurse with wide character support by adding the "--enable-widec" compile command, I explain you how I've compiled that on my Slitaz :

    The first thing to do is to download the Slitaz cooking wok :
    tazpkg get-install mercurial
    hg clone /home/slitaz/wok-slitaz

    (note : I download it in home/slitaz/wok-slitaz because I don't want to overwrite the receipt I create in home/slitaz/wok)

    Then I copy receipts and stuffs for nano and ncurses in my own wok :
    cd /home/slitaz/wok-slitaz
    cp -a nano ncurse* ../wok

    At this step, if I compile nano (in Slitaz it's the version 2.0.9) I obtain the same error about UTF-8 support. Note : recompile C library seems hard to me, so I've tried to recompile ncurses first hopping to solve the problem.

    I add the wide characters support in ncurses : I add --enable-widec compile command, then the compile rules in ncurses receipt is :
    # Rules to configure and make the package.
    sed -i 's|\tsh $(srcdir)/|\tash $(srcdir)/|' \
    ./configure --prefix=/usr \
    --libdir=/lib --sysconfdir=/etc \
    --infodir=/usr/share/info --mandir=/usr/share/man \
    --with-shared --without-debug --without-ada \
    --enable-widec \
    make &&
    make DESTDIR=$PWD/_pkg install

    I cook ncurses :
    tazwok cook ncurses

    I reinstall ncurses and ncurses-dev :
    tazpkg install /home/slitaz/packages/ncurses-5.7-dev.tazp
    kg --forced
    tazpkg install /home/slitaz/packages/ncurses-dev-5.7-.taz
    pkg --forced

    I cook nano :
    tazwok cook nano

    And there's no more UTF-8 error, so I guess it solve your problem. I let you make the tests and tell me if it's ok.

    Note : the officials Slitaz packages, as vte, are cooked with the ncurses wich don't have wide characters support enable. Maybe we must recompile them to have good results and solve somes terminal problems for exemple. I will try to install a UTF-8 system for more tests.
  • panksopankso February 2010

    Gokhlayeh is right, we need a ncursesw package and rebuild all ncurses apps who can do UTF-8. I'm working on this and still have to make some choice and testing before pushing to SliTaz repos.
  • LuXLuX February 2010

    @ Go Khla Yeh: this sounds great! I will try it tonight.

  • LuXLuX February 2010

    I've just tried it, with two little differences :

    - I haven't cloned the online wok, because my 20Go HD is almost full at the moment, and since I won't change it for a while I have to be very carefull not to fill it up definitely. Since ncurses was installed I simply copied its receipt from /var/lib/tazpkg/installed. I hope this doesn't mind.

    - Instead of installing my own ncurses with the --forced option, I first removed the installed one with "tazpkg remove ncurses" and then installed the cooked package with "tazpkg install".

    Surprisingly enough, although the compilation seems to have worked properly (it was very long and produced a huge list of messages, but I suppose that it is normal) the result is drasticly different: no terminal at all is working now, and nano (in tty) doesn't work either because, as is written in boot.log (and running nano produces the same message):
    /usr/bin/reset: error while loading shared libraries: cannot open shared object file: No such file or directory

    Indeed the only remaining libncurses* files outside /home are /lib/libncurses++w.a and /lib/libncurses.a, which come from ncurses-dev, I think. The missing libraries* exist however, they are still in /home/slitaz/wok/ncurses/ncurses-5.7/lib. These is probably due to the fact that the receipt contains the following lines, which were written for the official ncurses package, whose libraries are* (no 'w' at the end):
        # Libs.
    cp -a $_pkg/lib/* $fs/lib
    strip --strip-unneeded $fs/lib/*.so*

    I have tried to copy by hand the* libraries from /home to /lib but it did not change anything: neither xterm nor any terminal work, apparently because they require*, which is logical since they were compiled for ncurses without --enable-widec. This is probably what Pankso had in mind when he wrote:
    * Pankso has written
    we need a ncursesw package and rebuild all ncurses apps who can do UTF-8.

    A temporary solution would be to fix the new receipt of ncurses, and then recompile every program depending on it. Huh! I suddenly feel a little bit lazzy. I think I will simply remove my ncurses, re-install the official one and... go to bed.

    Best regards,
  • panksopankso February 2010

    Work in progress, just commited ncursesw packages (nano, dialog and more will follow):

    Some package using ncurses libs dont support wide char, so ncurses and ncursesw will be both installed by default. Since the 2 package use same terminfo and tabset I splited ncurses to have ncurses-common.

    - Christophe
  • LuXLuX February 2010
    Hello Pankso/Christophe,

    Great work, thank you very much!

    Et maintenant, dodo ! :-)
  • panksopankso February 2010
    bonne nuit...
  • jf_jf_ February 2010
    not too sure whether this is related (i think so), but i get problems listing files with names in another language. BUT if i ssh in to slitaz from another box that's fine, the filenames display properly in that terminal...
  • LuXLuX February 2010
    Hello jf_

    if your file names are encoded in UTF-8 (which is plausible) and you use an OS with Latin1 encoding OR list your files in a terminal which doesn't support UTF-8 encoding like xterm, non-ascii caracters won't be displayed properly. This is normal.

    Note that if you read the content of these files in the terminal, with less, vi, nano, and so on, you will have the same problem.

    On the other hand if you connect to Slitaz from another computer using UTF-8 encoding and an UTF-8 compliant terminal like uxterm, urxvt, xfce4-terminal, vte-terminal, lxterminal, and so on, you won't have any problem since the terminal you are using matches the encoding of your files.


This discussion has been closed.
← All Discussions

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

SliTaz Social