| Summary: | gnome-extra/gal-1.99.7 fails to build, "nonworking" iconv | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | giggles1 <bevdv> |
| Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | config.log as requested | ||
|
Description
giggles1
2003-07-12 12:10:31 UTC
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. |
