lists at wildgooses
Jun 3, 2010, 3:42 AM
Hi, replying here rather than on the bug tracker, but please set me
ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc)
straight if it's better discussed elsewhere?
(In reply to comment #11 - Diego)
> The problem is not build, the problem is that if libiconv is removed
> gcc is mergedů it breaks.
I have seen you and others note this several times (and the reason why
seems clear), however, what I don't get is why this is any different to
the normal situation with glibc?
Q: Why would libiconv ever be uninstalled/removed?
Q: After installing libiconv and rebuilding gettext/gcc, the upgrade
process to a new libiconv presumably then becomes, 1) upgrade libiconv,
2) rebuild gettext/gcc, 3) delete old libiconv libraries? Sounds bearable?
Is the problem that under glibc there is no dependency created at all
with regards to iconv, but if libiconv is floating around then there is
a dep created? And subsequently it's "hard" to avoid recompiles of gcc
picking up libiconv, hence ever removing that dependency?
Is this basically the same issue with gettext on uclibc?
I guess the real question here is what's the best way to build glib
under uclibc? Recommendations please?