The two tarballs are dummy libs to replace missing libintl and libiconv in uclibc. gtk+-2.10.14-libintl.diff adds a missing -lintl to Makefiles, since the configure script doesn't add it when bind_textdomain_codeset() is present in a shared lib. gtk+-2.10.14-libtool.diff fixes where libtool search shared libs. It was always searching in my build system and not in host system libdir. gtk+-2.10.14-nocups.diff removes cups backend. With these patches I could successfully cross compile x11-libs/gtk+-2.10.14 against uclibc in armv5te-ppc-linux-uclibc. Reproducible: Always
Created attachment 125751 [details] dummy iconv lib for uclibc
Created attachment 125752 [details] dummy intl for uclibc
Created attachment 125754 [details, diff] gtk+-2.10.14-nocups.diff
Created attachment 125755 [details, diff] gtk+-2.10.14-libtool.diff
Created attachment 125757 [details, diff] gtk+-2.10.14-libintl.diff
This is a huge amount of changes for us to have locally. Could you sumbit them upstream and paste the URL here? I'd like to get their comments at least before putting anything this intrusive into portage.
I would separate the handling of nls and iconv. nls should be handled generally within glib-2, providing a proper gi18n.h and gi18n-lib.h covering the case not having libintl.h with dummy macros for gettext() and friends. Most gnome apps can be compiled by replacing libintl.h with gi18n.h. Another possibility would be to create a dummy libintl.h that is copied into the source root after configure is ran, since all apps will have an include search path pointing there to find config.h, they can be compiled (I used the latter and compiled the whole gnome suite against uClibc, but also applied the first proposed change to glib-2). The implementation could maybe go to the gnome eclass. I think sed -i s/libintl.h/gi18n.h would be an upstream acceptable solution. uClibc provides a possibility to enable nls, but I would not do it as it does not really provide gettext/libintl replacement. A "correct" glib-2 app should not use directly iconv(), since glib-2 provides g_iconv/g_iconv_open/g_iconv_close so I would limit the iconv() related changes to glib-2 only (this assumption should though be checked with the gnome upstream developers), and use g_* instead of iconv*. For glib-2 used in conjunction with uClibc we have the options: 1. enable iconv() in uClibc's libc (UCLIBC_HAS_LOCALE) 2. if iconv is disabled there are 2 variants floating around: - provide really no-op dummies (I would extend though the ones proposed in one of the already attached tarballs to set errno when appropiate, telling the app that it does not support the functionality) - yvasilev's mini-iconv that supports a subset of the iconv functionality - compile libiconv within glib-2 build (using only the static library, so that we do not depend later on the shared one) and use that to compile glib-2 (using libiconv system-wide is not OK, as it will introduce dependency even in gcc if we provide the shared library, if only the static one is provided, it would make many binaries bigger) And now to gtk+, neither nls nor iconv is needed as long as glib-2 is modified as I proposed to provide correct gi18n.h and sources are corrected to use gi18n.h instead of libintl.h, the configure test should be disabled or made non-critical.
(In reply to comment #7) In the next update to my ARM base system I'll follow your advice. Thanks for the info.
(In reply to comment #7) > - yvasilev's mini-iconv that supports a subset of the iconv functionality Anyone knows where I can find this mini-iconv?
google for yvasilev zentoo, Index of /zentoo/; /zentoo/test/overlay/dev-libs/glib/files
Is upstream aware of this problem? (if still valid)
i doubt upstream cares about systems that lack i18n and l10n support
Gnome team, are we willing to use this set of patches downstream? If not, we should probably close this as "WONTFIX" since upstream could be non interested per comment #12
(In reply to comment #13) > Gnome team, are we willing to use this set of patches downstream? If not, we > should probably close this as "WONTFIX" since upstream could be non interested > per comment #12 > With the latest advancements in SoC CPUs (ARM Cortex et al.), pretty much everything can run gnu's libc without effort so I question the relevance of these patches nowadays.
This is valid as it's ever been and glibc is not fitting for every setup plus these patches are pretty trivial to maintain. These efforts to create code pulled together community members towards a goal. Sadly upstream gnome team is as messed up as we are. In that some developers "get it" and apply patches where they can, and others come along and make it harder for those in the know. However before this bug can really solve stuff, glib-2 needs to be patched also. That one is the blocker for nearly all X/syslog-ng related activities.
Patches need to be reworked anyway since they are doing changes the wrong way. I'll try to find some time to work on that.
