| Summary: | [dev-libs/glib] Why is glib-2.6* hard-masked in the uclibc profile? | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sander Knopper <sander> |
| Component: | New packages | Assignee: | Embedded Gentoo Team <embedded> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | enhancement | CC: | bertrand, gnome, jens, joshin, natanael.copa, remybosch, yoshi3 |
| Priority: | Lowest | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
glib-2.16.2.ebuild
glib-2.16.2-nls.patch |
||
|
Description
Sander Knopper
2005-09-01 04:58:39 UTC
As far as I understand it is masked because of the iconv issues and that the glib ebuild maintainer don't want to implement a --with-libiconv=gnu specific for uclibc (or the alternativ, to patch the language internals of glib to believe it is being translated, while it really isn't) That's too bad, especially because it seems to work like a charm from my point of view. Hereby a call to add uclibc flag to glib-2.x Too many apps rely on it to ignore... MC and xmms2 are my favourites. A change from enhancement to major would be appropriate imho. It's no stopper, just a big pain in the... Please.... Much appreciated. Remy Even got a patch ;)
--- glib-2.6.5.ebuild 2005-09-10 14:05:30.000000000 +0200
+++ glib-2.6.5-r1.ebuild 2005-10-10 16:39:51.000000000 +0200
@@ -11,7 +11,7 @@
LICENSE="LGPL-2"
SLOT="2"
KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ~ppc-macos ppc64 s390 sparc x86"
-IUSE="doc hardened static"
+IUSE="doc hardened static uclibc"
DEPEND=">=dev-util/pkgconfig-0.14
>=sys-devel/gettext-0.11
@@ -46,6 +46,7 @@
--with-threads=posix \
`use_enable static` \
`use_enable doc gtk-doc` \
+ `use_with uclibc "libiconv=gnu" ` \
|| die
emake || die
Reassigning for ulibc (In reply to comment #4) > Even got a patch ;) > > --- glib-2.6.5.ebuild 2005-09-10 14:05:30.000000000 +0200 > +++ glib-2.6.5-r1.ebuild 2005-10-10 16:39:51.000000000 +0200 > @@ -11,7 +11,7 @@ > LICENSE="LGPL-2" > SLOT="2" > KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ~ppc-macos ppc64 s390 sparc x86" > -IUSE="doc hardened static" > +IUSE="doc hardened static uclibc" > > DEPEND=">=dev-util/pkgconfig-0.14 > >=sys-devel/gettext-0.11 > @@ -46,6 +46,7 @@ > --with-threads=posix \ > `use_enable static` \ > `use_enable doc gtk-doc` \ > + `use_with uclibc "libiconv=gnu" ` \ > || die > > emake || die This is the wrong fix. granted it may work but its the wrong fix. i managed to build glib 2.10.3 in uclibc system. i had to - remove it from profile mask - install libiconv manually (since it does not provide virtual/iconv somehow) and it went fine. i installed newest ~M libiconv-1.11 and after that i tried building glib and mc . it works just fine. are there some issues with libiconv? yeah, it's called gcc fails to compile This have been an issue for years. I have been thinking of xfce4 too lately (specially worth the 4.4 release - im using it on my freebsd laptop and its awesome) What are the alternatives for a proper fix? There used to be patches to remove the iconv dependency from glib. Should we try to get that in again? Or is a iconv "fake" in uclibc the way to go? I think its about time to get this fixed. One solution might be to lift a mini iconv() from the mozilla projects Have a look at psm's comment in #186342 https://bugs.gentoo.org/show_bug.cgi?id=186342#c7 Basicly, there are only a handful apps that really need iconv. glib-2 is one of those. It should be possible to static link a dummy iconv for those. Once glib-2 is resolved it should be theoretically possible to build the entire gnome against uclibc. (given that you s/libintl.h/gi18n.h/ and s/iconv*/g_iconv*/) Created attachment 149093 [details]
glib-2.16.2.ebuild
this ebuild should fix this issue with minimal patching (so gnome herd might accept it this time)
Created attachment 149094 [details, diff]
glib-2.16.2-nls.patch
The ebuild only applies this patch and run autoconf if USE=nls so it should not affect glibc systems at all and it fixes a long-long-time annoyance in uclibc. Please consider commit this and unmask glib-2 for uclibc.
Diff for your convenience. --- glib-2.16.2.ebuild.orig 2008-04-08 11:51:02 +0000 +++ glib-2.16.2.ebuild 2008-04-08 11:34:19 +0000 @@ -2,15 +2,18 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/dev-libs/glib/glib-2.16.2.ebuild,v 1.1 2008/04/02 19:18:04 leio Exp $ -inherit gnome.org libtool eutils flag-o-matic +inherit gnome.org libtool eutils flag-o-matic autotools DESCRIPTION="The GLib library of C routines" HOMEPAGE="http://www.gtk.org/" +SRC_URI="${SRC_URI} + http://distrib-coffee.ipsl.jussieu.fr/pub/linux/alpine/alpine/mini-iconv/mini-iconv.tar.bz2" + LICENSE="LGPL-2" SLOT="2" KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~sparc-fbsd ~x86 ~x86-fbsd" -IUSE="debug doc fam hardened selinux xattr" +IUSE="debug doc fam hardened nls selinux xattr" RDEPEND="virtual/libc virtual/libiconv @@ -49,6 +52,12 @@ # Fix gmodule issues on fbsd; bug #184301 epatch "${FILESDIR}"/${PN}-2.12.12-fbsd.patch + # NLS issues for uclibc + if ! use nls; then + epatch "${FILESDIR}"/${PN}-2.16.2-nls.patch + eautoconf + fi + [[ ${CHOST} == *-freebsd* ]] && elibtoolize } @@ -63,6 +72,16 @@ # -- compnerd (3/27/06) use debug && myconf="--enable-debug" + # GNU libiconv causes problems for uclibc. Use static mini-iconv. + if ! use nls; then + cd "${WORKDIR}/mini-iconv" + emake static + append-flags -I"${WORKDIR}/mini-iconv" + append-ldflags -L"${WORKDIR}/mini-iconv" + myconf="${myconf} --disable-nls --with-iconv=native" + cd "${S}" + fi + # always build static libs, see #153807 econf ${myconf} \ $(use_enable xattr) \ RESOLVED as OBSOLETE since there is no update and package is far more updated Coordinated with leio |
