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 |