2005/9/5, Peter S. Mazinger <[EMAIL PROTECTED]>:
> 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.
--
[email protected] mailing list
