[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-embedded
Subject:    Re: [gentoo-embedded] problems with localization uclibc
From:       "Peter S. Mazinger" <ps.m () gmx ! net>
Date:       2005-09-12 7:18:15
Message-ID: Pine.LNX.4.44.0509120843120.9303-100000 () lnx ! bridge ! intra
[Download RAW message or body]

On Mon, 5 Sep 2005, René Rhéaume wrote:

> 2005/9/5, Peter S. Mazinger <ps.m@gmx.net>:
> > 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.
> Are the iconv and nls functionnality provided inside
> libuClibc-${version}.so or as separate libraries inside /lib?
> Where can I grab a stage tarball with this µclibc?

iconv() is in libc (like glibc does), libintl is a separate lib.
Any of the uclibc versions have these, libintl is not built though.
You have to be aware that if you enable one of these, there is no way back 
anymore!!

>  
> > 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.

virtual/glib2 ?

> 
> > 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.
> I can say from experience that libiconv is very instrusive. I had to
> resort to my older binary packages built without libiconv to solve the
> bad situation I was.
> 
> > 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
> I wonder if having virtual/iconv and virtual/gettext would help both
> us and Gentoo-FreeBSD.

that would be a more correct solution ...

> 
> > 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.
> Can this be done in a revision of uclibc-0.9.27?

yes, I am doing it all the time for any pkgs needing libintl.h (I 
personally do not enable libintl support in uclibc either, only iconv)

> 
> > Due to the way I modified my build system I won't provide files/patches
> > ... for the above, until
> Until when or what?

Until glib2 is solved in the portage tree for use elibc_uclibc 
(non-iconv/non-nls support added). The one willing to add it to the tree 
should contact me for the latest/greatest version ;)

> > 
> > ... 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)
> Did you try to submit your glib2 patch upstream? You never know.

The patch is not acceptable upstream, because upstream does not want to 
support the non-nls and non-iconv case, so it can only be used 
conditionally for ( use elibc_uclibc &&  ! ( use nls ||  use iconv ) )
(iconv if implemented).

Peter

-- 
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@gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]