I see that a similar bug for gal-0.22 is listed as resolved (why did the verion number jump so much??) Well, I still get the same error with gal-1.99.7 that I had with the earlier version: checking for iconv in -liconv... no checking for iconv... yes checking for gnu_get_libc_version... yes checking if iconv() handles UTF-8... no configure: error: You need to install a working iconv implementation, such as ftp://ftp.gnu.org/pub/gnu/libiconv !!! ERROR: gnome-extra/gal-1.99.7 failed. !!! Function econf, Line 304, Exitcode 1 !!! econf failed I seem so recall at the time that emerging libiconv, then gal, then unmerging libiconv, then re-emerging glibc did the trick. I don't really care to go through all that again. Is this just something that is going to have to wait for glibc-2.3.2 which has an iconv that "works"? Reproducible: Always Steps to Reproduce: 1. 2. 3. please:/usr/portage# emerge info Portage 2.0.48-r1 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4) ================================================================= System uname: 2.4.20-ck6 i686 AMD Athlon(tm) MP 2000+ GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/usr/local/portage" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 oss apm cups mad mikmod nls xml2 gdbm slang bonobo ruby libwww motif X 3dnow mmx directfb sse dga opengl xv fbcon kde qt qtmt arts tcltk aalib imlib ncurses readline sdl svga lcms gif jpeg png tiff gd avi mpeg quicktime esd gtk gtk2 -gnome alsa ggi dvd xmms oggvorbis encode pam ssl crypt tcpd mozilla spell truetype xml pdflib plotutils tetex guile perl python libg++ atlas pic berkdb mysql postgres odbc samba gpm zlib java" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-mp -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=athlon-mp -O2 -pipe -fomit-frame-pointer" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j4" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache fixpackages"
you should not need to. did you emerge glibc with the "nls" useflag? would you be able to attach the config.log file from the gal work directory so we can see what exactly is the error?
Created attachment 14423 [details] config.log as requested
OK, since I now also have the "PHP Ebuild crashes on libiconv", I decided, in a fit of disgust, to install glibc-2.3.2 to try and fix things. But to my surprise, still neither ebuild works, and I still get bryan@please bryan $ iconv -f UTF-8 -t ISO-2022-JP /tmp/simple.txt iconv: conversion to `ISO-2022-JP' is not supported I guess I was under the impression that the iconv in glibc-2.3.2 "worked" (whatever that means), but apparently I was mistaken. What *exactly* is the problem here, and what is needed to resolve this mess?
Adding LDPATH="/usr/lib/gconv" to a file in /etc/env.d fixes the problem (at least with glibc-2.3.2 installed). I had forgotten about this from the other gal/iconv bug. Although once I saw that suggestion again just now, I seemed to recall already having done this at some point in the past. But if I did, it got undone. Anyway, gal builds now but this all still seems a bit sketchy.
well, -liconv is supposed to fail in this instance, because we don't use libiconv, it creates alot of problems down the line if you do. gal and others are supposed to use glibc's version of iconv (afaik, it is implemented inside libc). according to the config log, it finds iconv in glibc but as you note, it fails to find all the encodings and locales. oh and btw, the version numbers jumped because this version of gal is for gtk2 whereas the 0.2x is for gtk1. now, the error message in the configure file is misleading, because it naively assumes failure means missing iconv, which is not the case here. it is interesting that your glibc can be fooled by adding /usr/lib/gconv to your LD_PATH. can you try: strings /lib/libc.so.6 | grep /usr/lib/gconv it should at least find one reference, which is where it searches for these encoding modules. if it doesn't return anything or does not point to /usr/lib/gconv, then there is a problem with your glibc
Right, I realize that -liconv is nettlesome, and all trace of it have been eradicated from this system. libc does have the references: bryan@please default $ strings /lib/libc.so.6 | grep /usr/lib/gconv /usr/lib/gconv /usr/lib/gconv/gconv-modules.cache but I don't think the LDPATH trick is unique to me; it was mentioned in the other bug report.
well.. same problem here.
Well. i was getting this same error when compiling gnome-extras/gal but after doing: # echo "/usr/lib/gconv" >> /etc/ld.so.conf # ldconfig It is finally now compiling. Looks like sombody forgot to add something to /etc/ld.so.conf file after implementing the latest glibc into the portage tree.
closing, since we cant reproduce and the problem seems to have dissapeared after these 2 reports.
