On Tuesday 18 October 2011 05:27:32 Ed W wrote: > > you aren't the first person to find this behavior undesirable, and when i > > implemented it, it was more of "let's save space on things i don't think > > anyone will use". but if people are using it, then installing these > > things probably makes sense. > > I concede to being somewhat confused on how all the various pieces > integrate, but iconv seems like an increasingly useful piece, even if > only in a flawed capability that supports only 7 bit to UTF-8 and vice > versa.
the issue is that the current cross-compilers delete the `iconv` binary that is cross-compile to run on CHOST, not CBUILD. the native CBUILD `iconv` is still available. if you want to use sys-libs/glibc for a target, atm you need to compile it for the target: CBUILD=x86_64 CHOST=arm CTARGET=arm. > 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 ... -mike
signature.asc
Description: This is a digitally signed message part.
