Apparently the sys-libs/glibc-2.7-r1 ebuild specifies IUSE="gd" The "gd" USE flag is described as the media-libs/gd graphics manipulation library in use.desc; however, enabling this flag on glibc does not pull in media-libs/gd as a dependency, so at the very least this flag's description is not applicable to glibc. Furthermore, skimming the glibc ebuild and its included eclasses, there don't appear to be any other references to the "gd" USE flag at all (though I could be missing something).
(In reply to comment #0) > Furthermore, skimming the glibc ebuild and its included eclasses, there don't > appear to be any other references to the "gd" USE flag at all (though I could > be missing something). Yeah, you missed the whole ${PORTDIR}/sys-libs/glibc/files/eblits/ thing...
glibc does use gd when USE=gd ... it creates graphical test apps that link against gd
Then it needs a dependency doesn't it?
i'm not adding a dep on gd in glibc
*** Bug 300367 has been marked as a duplicate of this bug. ***
*** Bug 326213 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > i'm not adding a dep on gd in glibc > Then how about removing the associated USE flag and preventing the programs requiring the dep from being built?
Or, putting the bits that depend on gd into a separate ebuild?
I'd like to challenge the WONTFIX decision. The use flag causes some programs (like memusagestat) to be build with symbols referencing libgd. In an environment that uses binpackages this can cause revdep-rebuild to keep falling over glibc: re-emerging doesn't fix the situation, although the use flag is set. I think *something* needs to be done.
This also means, IIRC, that even in a non-binpkg environment, if you remove other software depending on gd (not a stretch, in a server environment) and thus emerge --depclean gets rid of gd altogether, you now have broken binaries from glibc because of a dependency failure, but one which again won't be resolved with revdep-rebuild.
*** Bug 425324 has been marked as a duplicate of this bug. ***
*** Bug 435574 has been marked as a duplicate of this bug. ***
Can anybody explain why this problem can not be solved? Thanks.
(In reply to comment #13) > Can anybody explain why this problem can not be solved? > Thanks. Because the built tools are not important at all, and adding the dependency would only introduce circular dependency for a toolchain@ owned package If you really find these tools useful, just record media-libs/gd in your world # emerge --noreplace media-libs/gd or # emerge media-libs/gd
(In reply to comment #14) > Because the built tools are not important at all, and adding the dependency > would only introduce circular dependency for a toolchain@ owned package Сircular dependency - not an argument, because if there is a need to install glibc with these tools, and no media-libs/gd in system, glibc does not install them, although USE=gd is set. This is wrong. In any case it is necessary to recompile glibc after installing media-libs/gd, which is equivalent to resolve circular dependency (USE=-gd emerge -1 glibc && emerge -1 media-libs/gd && USE=gd emerge -1 glibc) Necessary to do the same thing, but in the current situation caused strange collision. After all, if these tools are unimportant, put "sys-libs/glibc gd" into use.mask in profile. I do not think this bug should be marked as WONTFIX. > If you really find these tools useful, just record media-libs/gd in your > world In my binhost I put "sys-libs/glibc -gd" into p.use. However, I spent a lot of time to find out the causes of broken dependencies. I do not like the situation. And not to me alone, according to so many reports that duplicate this.
