>> Some experimentation with latest uclibc suggests that it has some
>> working iconv capability, although it appears to also cause a limited
>> locale implementation to be pulled in (which I really don't have a
>> requirement for). I haven't tried to use it in anger, but for example
>> it allows a bunch of ebuilds to compile which previously moaned about
>> missing iconv implementations (admitedly those with tests claiming that
>> the uclibc iconv is incomplete...)
> this is iconv() from the C library, not the `iconv` binary.
>
> i wish locale support in uClibc was more feature complete ...
On my uclibc box (no libiconv)
root@localhost $ ls -al /usr/bin/iconv
-rwxr-xr-x 1 root root 10878 Oct 19 19:22 /usr/bin/iconv
root@localhost $ ldd /usr/bin/iconv
libc.so.0 => /lib/libc.so.0 (0x9ff12000)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x9ff75000)
I would really like to get some proxy developer to help me get uclibc
updated and also some patches to a few ebuilds (we hardly need any with
latest uclibc, at least on x86)
See here:
https://bugs.gentoo.org/show_bug.cgi?id=308477#c21
...for some notes on building uclibc iconv *under* a uclibc build root
(needs some tweaking to help the build succeed - would like to see those
tweaks hit upstream, but ...). The main snag is that you get iconv
*and* locale... I don't yet have a use for locale, but setting it to
build only en_gb.utf8 seems to work and I think total incremental
library install size was around 40-50KB
(I also noticed a plausible implementation of a functioning gettext
libintl.h ... ?)
Seems like uclibc has *near* correct working iconv and could do with
word getting out so it gets more exposure and hopefully soon a fully
working implementation..
Cheers
Ed W
