1 |
2005/9/5, Peter S. Mazinger <ps.m@×××.net>: |
2 |
> Localization in gentoo-uclibc: |
3 |
> glibc's localization provides iconv (what libiconv would provide) and |
4 |
> libintl functionality (the latter one is what is covered really by |
5 |
> USE=nls), it additionally requires gettext mostly to build packages but |
6 |
> not for runtime uclibc (this is not the state of the ebuilds in the tree |
7 |
> though and be warned, don't enable nls for current masked uclibc ebuilds |
8 |
> because that part of the ebuild is incorrect !!!) provides a subset of |
9 |
> iconv (allows to build everything I ever tested - for ex. the |
10 |
> full gnome suite, kde is almost finished too -not related to this though) |
11 |
> that is currently provided by the pulled-in libiconv, and the libintl |
12 |
> functionality that is provided by the pulled-in gettext. The libintl |
13 |
> functionality in uClibc was disabled by it's developer, because it can't |
14 |
> "yet" be used as a full replacement for nls related stuff (but it is |
15 |
> enough to build anything needing |
16 |
> textdomain/bindtextdomain/bind_textdomain_codeset and *gettext. |
17 |
Are the iconv and nls functionnality provided inside |
18 |
libuClibc-${version}.so or as separate libraries inside /lib? |
19 |
Where can I grab a stage tarball with this µclibc? |
20 |
|
21 |
> To overcome this it would be possible to create a glib2-uclibc package |
22 |
> that would provide dev-libs/glib-2. Until there is no solution to glib2 it |
23 |
> is no use to go further. |
24 |
|
25 |
> As I said in the bug mentioned in this thread, I would ban |
26 |
> libiconv/gettext completely from the uclibc profiles, because they only |
27 |
> call for trouble, you can maybe build some more packages, but later you |
28 |
> nuke your gcc compiler for ex. |
29 |
I can say from experience that libiconv is very instrusive. I had to |
30 |
resort to my older binary packages built without libiconv to solve the |
31 |
bad situation I was. |
32 |
|
33 |
> To disable DEPEND for these 2 packages (until they maybe will be masked) |
34 |
> I add sys-devel/gettext-99999 and dev-libs/libiconv-99999 to |
35 |
> /etc/portage/profile/package.provided |
36 |
I wonder if having virtual/iconv and virtual/gettext would help both |
37 |
us and Gentoo-FreeBSD. |
38 |
|
39 |
> Possibilities currently to overcome libintl.h needs: |
40 |
> a. provide a dummy libintl.h for the pkg (touch ${S}/libintl.h is |
41 |
> mostly sufficient) |
42 |
> b. provide dummy functions for *gettext *textdomain* needed by a package |
43 |
> in this libintl.h file. |
44 |
Can this be done in a revision of uclibc-0.9.27? |
45 |
|
46 |
> Due to the way I modified my build system I won't provide files/patches |
47 |
> ... for the above, until |
48 |
Until when or what? |
49 |
> |
50 |
> ... it is possible that one stubborn maintainer can block an addition |
51 |
> because he does not need it and has no interest in supporting uclibc (he |
52 |
> also blocked a similar patch to gtk+ for 6 month, saying it won't be |
53 |
> acceptable upstream, I have sent the patch upstream, they accepted it |
54 |
> within 1 working day and added it to cvs, but gentoo didn't got the change |
55 |
> into gtk+ x86 stable ... search gtk+ and ngettext in bugs.g.o, although |
56 |
> the solution presented there is not quite correct, it should handle |
57 |
> plural case too) |
58 |
Did you try to submit your glib2 patch upstream? You never know. |
59 |
|
60 |
-- |
61 |
gentoo-embedded@g.o mailing list |