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
--
[email protected] mailing list
