[gentoo-embedded] problems with localization uclibc

[gentoo-embedded] problems with localization uclibc

[Natanael Copa]

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)

-- 
Natanael Copa

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] problems with localization uclibc

[Walter Goossens]

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)

Walter Goossens
-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] problems with localization uclibc

[Natanael Copa]

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

-- 
gentoo-embedded@gentoo.org mailing list

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

Re: [gentoo-embedded] problems with localization uclibc

[René Rhéaume]

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

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

> Due to the way I modified my build system I won't provide files/patches
> ... for the above, until
Until when or what?
> 
> ... 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.

-- 
gentoo-embedded@gentoo.org mailing list

Re: [gentoo-embedded] problems with localization uclibc

[Peter S. Mazinger]

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