From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] uclibc: deprecate locale support
Date: Sun, 28 Jun 2015 15:08:22 +0200 [thread overview]
Message-ID: <20150628150822.46f6861e@free-electrons.com> (raw)
In-Reply-To: <20150628125837.GX31780@waldemar-brodkorb.de>
Hello,
On Sun, 28 Jun 2015 14:58:37 +0200, Waldemar Brodkorb wrote:
> I think no package really needs locale support in the C library.
>
> May be there is some misunderstanding about the locale stuff.
> Here is how I understand the stuff.
>
> I think we have mixed up two different things here:
> - iconv: perform character set conversion, needed for a lot of
> packages, f.e. Kodi. Is included in Glibc and Musl. Libiconv can
> be used with uClibc-ng/uClibc.
> - locale: defines the user's language, country, ..
> If you want f.e. german error messages on your embedded system
> you would need locale support and locale data.
> env LC_ALL=de_DE ls foo
Fully agreed here. But in uClibc, enabling locale support actually
gives both: the iconv functions *and* the locale support itself.
> Who is really using the locale stuff?
> I think the iconv functions, which are automatically enabled
> when UCLIBC_HAS_LOCALE is set are neither complete not used
> externally.
Of course they are used externally: many of our packages do "select
BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE" because they
unconditionally use the iconv function, and uClibc only provide these
functions if locale support is enabled. From
libc/misc/wchar/Makefile.in (in original uClibc, I haven't looked at
uClibc-ng) :
CSRC-$(UCLIBC_HAS_LOCALE) += iconv.c
> If libiconv is to big, libiconv-tiny for simple UTF-8 <-> ASCII
> conversion could be used.
This could be useful, but this would be a separate matter.
> > If we remove BR2_TOOLCHAIN_BUILDROOT_LOCALE, then there's a lot of
> > possible further cleanup: BR2_ENABLE_LOCALE should be removed, all
> > packages doing select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE
> > should be changed, etc.
>
> May be something like this:
> select BR2_PACKAGE_LIBICONV if BR2_LIBC_WITHOUT_ICONV
Yes, correct.
> > Also, do you have an idea of what is the state of the locale
> > support in musl ? Does musl provide the functions provided by
> > libiconv ?
>
> Yes. Like GNU libc, musl already provides iconv functions out of the
> box.
Ok, so BR2_LIBC_WITHOUT_ICONV would be simple: it's y if uClibc, and n
otherwise.
Or should we instead have in uClibc the iconv functions enabled by
default (by having a UCLIBC_HAS_ICONV option separate from
UCLIBC_HAS_LOCALE), so that uClibc is like all other C libraries from
an iconv() point of view ? And of course, get rid completely of locale
support in uClibc ?
There are still lots of packages that use BR2_ENABLE_LOCALE in
Buildroot, we will have to check what they do exactly with it.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-06-28 13:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-28 7:14 [Buildroot] [PATCH] uclibc: deprecate locale support Waldemar Brodkorb
2015-06-28 9:50 ` Yann E. MORIN
2015-06-28 10:02 ` Waldemar Brodkorb
2015-06-28 12:01 ` Thomas Petazzoni
2015-06-28 12:58 ` Waldemar Brodkorb
2015-06-28 13:08 ` Thomas Petazzoni [this message]
2015-06-29 17:47 ` Waldemar Brodkorb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150628150822.46f6861e@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox