Re: [gentoo-embedded] problems with localization uclibc

[Peter S. Mazinger]

On Wed, 31 Aug 2005, Natanael Copa wrote:

Localization in gentoo-uclibc:
glibc's localization provides iconv (what libiconv would provide) and 
libintl functionality (the latter one is what is covered really by 
USE=nls), it additionally requires gettext mostly to build packages but 
not for runtime uclibc (this is not the state of the ebuilds in the tree 
though and be warned, don't enable nls for current masked uclibc ebuilds 
because that part of the ebuild is incorrect !!!) provides a subset of 
iconv (allows to build everything I ever tested - for ex. the 
full gnome suite, kde is almost finished too -not related to this though) 
that is currently provided by the pulled-in libiconv, and the libintl 
functionality that is provided by the pulled-in gettext. The libintl 
functionality in uClibc was disabled by it's developer, because it can't 
"yet" be used as a full replacement for nls related stuff (but it is 
enough to build anything needing 
textdomain/bindtextdomain/bind_textdomain_codeset and *gettext.

I have separated these into USE=iconv (not present in portage) and 
USE=nls.

There is a "stopper" bug for glib2 that does not allow anything to be done
properly in the portage tree (search for glib iconv gettext and/or nls or 
search for my name in bugs.g.o). The maintainer of glib2 does not accept a 
patch that would allow to allow to build glib on a system w/ USE=-nls.
I haven't seen any pkg that really requires USE=nls (built more then 300 
against uclibc), but the tree is full of DEPEND="sys-devel/gettext", iconv 
is good to have, else charset translations don't work (but the pkgs could 
be built w/o it though)

To overcome this it would be possible to create a glib2-uclibc package 
that would provide dev-libs/glib-2. Until there is no solution to glib2 it 
is no use to go further.

As I said in the bug mentioned in this thread, I would ban 
libiconv/gettext completely from the uclibc profiles, because they only 
call for trouble, you can maybe build some more packages, but later you 
nuke your gcc compiler for ex.

To disable DEPEND for these 2 packages (until they maybe will be masked)
I add sys-devel/gettext-99999 and dev-libs/libiconv-99999 to  
/etc/portage/profile/package.provided

Possibilities currently to overcome libintl.h needs:
a. provide a dummy libintl.h for the pkg (touch ${S}/libintl.h is 
mostly sufficient)
b. provide dummy functions for *gettext *textdomain* needed by a package 
in this libintl.h file.

Due to the way I modified my build system I won't provide files/patches 
... for the above, until

... it is possible that one stubborn maintainer can block an addition 
because he does not need it and has no interest in supporting uclibc (he 
also blocked a similar patch to gtk+ for 6 month, saying it won't be 
acceptable upstream, I have sent the patch upstream, they accepted it 
within 1 working day and added it to cvs, but gentoo didn't got the change 
into gtk+ x86 stable ... search gtk+ and ngettext in bugs.g.o, although 
the solution presented there is not quite correct, it should handle 
plural case too)

Peter

> Walter Goossens wrote:
>
> > Natanael Copa wrote:
> >
> >> Most of the problems I have been experiencing with gentoo embedded have
> >> been related to localization (gettext/libintl/libiconv). Here are some
> >> examples:
> >>
> >> 'make menuconfig' and 'make oldconfig' does not work out of the box
> >> (looks like they are experiencing this on uclibc list too?)
> >> http://thread.gmane.org/gmane.linux.gentoo.embedded/88
> >>
> >> Some applications don't link:
> >> for example eject (Adding LDADD=-lintl is a workaround)
> >>
> >> Some applications don't compile (at least gcc does not in ~x86:
> >> https://bugs.gentoo.org/show_bug.cgi?id=104237)
> >>
> >> Many ebuilds compile but has not proper RDEPEND. They often lack
> >> libiconv or gettext dependency.
> >> For example:
> >> gdb: readline libiconv
> >> eject: gettext
> >> mpd: libiconv
> >> mpc: libiconv
> >> cvs: gettext
> >>
> >> etc...
> >>
> >> Since this is a returning problem, I wonder if there is something we
> >> could do about it.
> >>
> >> Is a standard way to handle localization problems with uclibc?
> >>
> >> Should localization in uclibc be mentioned in developer docs?
> >>
> >> Should the ebuilds with dependency related problems be reported one by
> >> one or can we make a bulk? (ie try to find all affected ebuilds and
> >> report as single bug)
> >>
> >>
> >>
> > I've got that libiconv problem too using gentoo-embedded on a MIPS
> > system.
> > I'm unable to compile PHP due to this bug...
> >
> > If / when you find something out will you let us know?
> > I tried installing the separate libiconv from x86 but that isn't
> > really elegant and to make things worse, doesn't do the trick (for PHP
> > at least)
>
>
> There is an explanation here:
>
> https://bugs.gentoo.org/show_bug.cgi?id=104237
>
>
> It tells that gettext/iconv shouldn't be there at all. It is in my
> system (obviously) so I need to remove and recompile. (using
> rev-dep-rebuild --soname libiconv.so.2)
>
> Looks like it was fetchmail that pulled in gettext and gettext pulled in
> libiconv.
>
>
> --
> Natanael Copa
>
>

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

-- 
gentoo-embedded@g.o mailing list