Gentoo Archives: gentoo-embedded

From: "Peter S. Mazinger" <ps.m@×××.net>
To: gentoo-embedded@l.g.o
Subject: Re: [gentoo-embedded] problems with localization uclibc
Date: Mon, 12 Sep 2005 07:19:17
Message-Id: Pine.LNX.4.44.0509120843120.9303-100000@lnx.bridge.intra
In Reply to: Re: [gentoo-embedded] problems with localization uclibc by "René Rhéaume"
1 On Mon, 5 Sep 2005, René Rhéaume wrote:
2
3 > 2005/9/5, Peter S. Mazinger <ps.m@×××.net>:
4 > > Localization in gentoo-uclibc:
5 > > glibc's localization provides iconv (what libiconv would provide) and
6 > > libintl functionality (the latter one is what is covered really by
7 > > USE=nls), it additionally requires gettext mostly to build packages but
8 > > not for runtime uclibc (this is not the state of the ebuilds in the tree
9 > > though and be warned, don't enable nls for current masked uclibc ebuilds
10 > > because that part of the ebuild is incorrect !!!) provides a subset of
11 > > iconv (allows to build everything I ever tested - for ex. the
12 > > full gnome suite, kde is almost finished too -not related to this though)
13 > > that is currently provided by the pulled-in libiconv, and the libintl
14 > > functionality that is provided by the pulled-in gettext. The libintl
15 > > functionality in uClibc was disabled by it's developer, because it can't
16 > > "yet" be used as a full replacement for nls related stuff (but it is
17 > > enough to build anything needing
18 > > textdomain/bindtextdomain/bind_textdomain_codeset and *gettext.
19 > Are the iconv and nls functionnality provided inside
20 > libuClibc-${version}.so or as separate libraries inside /lib?
21 > Where can I grab a stage tarball with this µclibc?
22
23 iconv() is in libc (like glibc does), libintl is a separate lib.
24 Any of the uclibc versions have these, libintl is not built though.
25 You have to be aware that if you enable one of these, there is no way back
26 anymore!!
27
28 >
29 > > To overcome this it would be possible to create a glib2-uclibc package
30 > > that would provide dev-libs/glib-2. Until there is no solution to glib2 it
31 > > is no use to go further.
32
33 virtual/glib2 ?
34
35 >
36 > > As I said in the bug mentioned in this thread, I would ban
37 > > libiconv/gettext completely from the uclibc profiles, because they only
38 > > call for trouble, you can maybe build some more packages, but later you
39 > > nuke your gcc compiler for ex.
40 > I can say from experience that libiconv is very instrusive. I had to
41 > resort to my older binary packages built without libiconv to solve the
42 > bad situation I was.
43 >
44 > > To disable DEPEND for these 2 packages (until they maybe will be masked)
45 > > I add sys-devel/gettext-99999 and dev-libs/libiconv-99999 to
46 > > /etc/portage/profile/package.provided
47 > I wonder if having virtual/iconv and virtual/gettext would help both
48 > us and Gentoo-FreeBSD.
49
50 that would be a more correct solution ...
51
52 >
53 > > Possibilities currently to overcome libintl.h needs:
54 > > a. provide a dummy libintl.h for the pkg (touch ${S}/libintl.h is
55 > > mostly sufficient)
56 > > b. provide dummy functions for *gettext *textdomain* needed by a package
57 > > in this libintl.h file.
58 > Can this be done in a revision of uclibc-0.9.27?
59
60 yes, I am doing it all the time for any pkgs needing libintl.h (I
61 personally do not enable libintl support in uclibc either, only iconv)
62
63 >
64 > > Due to the way I modified my build system I won't provide files/patches
65 > > ... for the above, until
66 > Until when or what?
67
68 Until glib2 is solved in the portage tree for use elibc_uclibc
69 (non-iconv/non-nls support added). The one willing to add it to the tree
70 should contact me for the latest/greatest version ;)
71
72 > >
73 > > ... it is possible that one stubborn maintainer can block an addition
74 > > because he does not need it and has no interest in supporting uclibc (he
75 > > also blocked a similar patch to gtk+ for 6 month, saying it won't be
76 > > acceptable upstream, I have sent the patch upstream, they accepted it
77 > > within 1 working day and added it to cvs, but gentoo didn't got the change
78 > > into gtk+ x86 stable ... search gtk+ and ngettext in bugs.g.o, although
79 > > the solution presented there is not quite correct, it should handle
80 > > plural case too)
81 > Did you try to submit your glib2 patch upstream? You never know.
82
83 The patch is not acceptable upstream, because upstream does not want to
84 support the non-nls and non-iconv case, so it can only be used
85 conditionally for ( use elibc_uclibc && ! ( use nls || use iconv ) )
86 (iconv if implemented).
87
88 Peter
89
90 --
91 Peter S. Mazinger <ps dot m at gmx dot net> ID: 0xA5F059F2
92 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
93
94 --
95 gentoo-embedded@g.o mailing list