lists at wildgooses
Jun 3, 2010, 3:42 AM
Views: 917
Permalink
|
|
ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc)
|
|
Hi, replying here rather than on the bug tracker, but please set me
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
_after_
> 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?
Thanks
Ed W
|
ref bug 297229 (virutal/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc)
