An attempt to emerge dev-libs/glib in a healthy and recently bootstrapped prefix environment failed. From the console log: >>> Emerging (14 of 28) dev-libs/glib-2.16.3-r00.1 to / .... .... checking for libiconv_open in -liconv... no configure: error: *** No iconv() implementation found in C library or libiconv !!! Please attach the following file when seeking support: !!! /local/scratch/portage/dev-libs/glib-2.16.3-r00.1/work/glib-2.16.3/config.log * ERROR: dev-libs/glib-2.16.3-r00.1 failed: * econf failed * * Call stack: * ebuild.sh: 49: <call src_compile> * environment:2898: <call econf '--with-libiconv=gnu' '--disable-xattr' '--disable-man' '--disable-gtk-doc' '--disable-fam' '--disable-selinux' '--enable-static' '--with-threads=posix'> * ebuild.sh: 526: die "econf failed"
Created attachment 154443 [details] The config.log file.
WORKSFORME (on x86-linux) - You will have to provide more information in order to fix this. emerge --info, what "libiconv" packages you have installed, gcc version, etc. I'll leave this bug 'open' for now but if there is no more information I will close it later. Thanks for reporting, I hope we can get to the bottom of this. (Side note: I do see a libtool-2.2 issue with this package)
(In reply to comment #2) > WORKSFORME (on x86-linux) - You will have to provide more information in order > to fix this. I'll try to gather the info you need. `gcc --version' produces this: gcc (GCC) 4.2.3 (Gentoo 4.2.3 p1.0) I'm not sure how to find out about "libiconv". If I grep the emerge.log for 'completed emerge' I see mention of virtual/libiconv-0, but is that what you need? I'll attach the "completed emerge" lines anyway, and the output from `emerge --info'.
Created attachment 154517 [details] All 'completed emerge' lines from var/log/emerge.log.
Created attachment 154519 [details] The output from `emerge --info'.
iconv stuff is provided by glibc. Since you're on linux, you should have it in your glibc. What goes wrong here is that it looks as if there is no compilation attempted without -liconv. The real error is that the linker complains it can't find libiconv, which on linux feels correct to me.
Yea, I have a nearly identical setup here, besides the age of my prefix, and can't reproduce this error. Maybe the native glibc has something to do with it? I have no idea, really. Sorry. % rpm -q glibc glibc-2.3.4-2.36 Good luck =/
My native glibc is this one, > rpm -q glibc glibc-2.4-31.30 But I really don't suspect it since it has worked fine before. On the early morning of 2008-05-25 bootstrapping from scratch and emerging glib worked fine. I made a filtered diff-listing of emerge.log and it seems the only significant changes are these: Happy (2008-05-25): completed emerge (77 of 82) app-misc/ca-certificates-20070303-r1 to / completed emerge (80 of 82) sys-apps/portage-2.2.00.10385 to / Unhappy (2008-05-27): completed emerge (77 of 82) app-misc/ca-certificates-20080514 to / completed emerge (80 of 82) sys-apps/portage-2.2.00.10418 to / Guessing that ca-certificates are not important, doing a `diff -r' on sys-apps/portage yields diff -r 2008-05-25/usr/portage/sys-apps/portage/ChangeLog 2008-05-27/usr/portage/sys-apps/portage/ChangeLog 4a5,10 > *portage-2.2.00.10418 (25 May 2008) > > 25 May 2008; Fabian Groffen <grobian@gentoo.org> > -portage-2.2.00.10249.ebuild, +portage-2.2.00.10418.ebuild: > New snapshot, including trunk USE-deps feature Can this somehow have affected the "libiconv" problem?
I doubt a compiler/linker problem to be related to portage internal resolver changes. I would suspect gcc-config, which has new behaviour. But I can't come up with some reasoning that explains it (since you're using /usr/bin/gcc)
I've found a workaround. If I enter the prefix environment I can do this: emerge --unmerge man-pages (claimed to block libiconv) emerge libiconv emerge glib At this point I would like to re-emerge man-pages but I am getting sys-apps/man-pages (is blocking dev-libs/libiconv-1.11-r00.1) Is this blocking relation correct? I would have thought that man-pages are compatible with just about everything else?
man-pages contains "GNU/Linux" man pages, hence including iconv stuff (since it's in glibc). Therefore the conflict here. You shouldn't have libiconv on *-linux currently.
Good news, this morning glib was emerged successfully. I tried to do some comparisons, the only difference I could see is that the portage version has advanced from 2.2.00.10418 to 2.2.00.10347.
That's a "downgrade" actually. This bug is probably caused by something similar as in bug #224711
virtual/libiconv ebuild uses "!elibc_glibc? (..." which means this is bug is actually the same as bug #224711. The tree has been fixed for this.
