Hi, glibc-2.3.2-r9.ebuild contains the following dependency code: DEPEND=">=sys-devel/gcc-3.2.3-r1 !ppc? ( nptl? ( >=sys-devel/gcc-3.3.1-r1 ) ) This results in emerge crashing on everything, because all matching versions of ggc are masked. This is the emerge output: # emerge --deep --pretend world These are the packages that I would merge, in order: Calculating world dependencies / !!! all ebuilds that could satisfy ">=sys-devel/gcc-3.3.1-r1" have been masked. !!! (dependency required by "sys-libs/glibc-2.3.2-r9" [ebuild]) !!! Problem with ebuild sys-libs/glibc-2.3.2-r9 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. When I remove the 'nptl' flag from the USE list, everything works as expected. I am running a 2.6-kernel. The trouble started after I did an 'emerge sync' today. Do we really need such a bleeding edge compiler for NPTL all of a sudden? Regards, Toon. Reproducible: Always Steps to Reproduce: See de detailed description for the steps to reproduce. # emerge info Portage 2.0.49-r21 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3, 2.6.0-test8) ================================================================= System uname: 2.6.0-test8 i686 Pentium II (Klamath) Gentoo Base System version 1.4.3.10 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=i586 -O2 -pipe -fomit-frame-pointer" CHOST="i586-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=i586 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X509 apache2 apm berkdb cgi crypt cscope curl doc encode fam fastcgi foomaticdb gdbm gif gpm gtk2 imlib innodb ipv6 java javascript jdepend jpeg ldap libg++ libwww lids mad mbox mikmod milter mmx motif mpeg mysql ncurses nls nptl oav odbc oggvorbis pam parse-clocks pcap perl plotutils png ppds python quicktime radius readline regexp sasl slang snmp socks5 spell ssl tcpd threads transparent-proxy truetype x86 xml2 xmms xv zlib"
yes, you do need such a bleeding edge compiler
This seems to be a bug -- isn't the usual Gentoo way to downgrade a package if suddenly a significant bug is found that depends on masked packages? This bug is causing me problems also.
i dont see the bug if you dont have a gcc-3.3.1-r1 or newer version of gcc, then dont put nptl into your USE, simple as that
*** Bug 38679 has been marked as a duplicate of this bug. ***
even if I have gcc-3.3.2-r5, I got same error, with USE="nptl"
whoops, i missed that, re-opening Bug 38679
*** Bug 38680 has been marked as a duplicate of this bug. ***
*** Bug 38681 has been marked as a duplicate of this bug. ***
*** Bug 38695 has been marked as a duplicate of this bug. ***
Lets just say 'nptl' is a bleeding edge USE flag ...
This is not invalid. The glibc-2.3.2-r9.ebuild depends on >=sys-devel/gcc-3.3.1-r1 and has been marked x86 but there is no x86 marked ebuild for >=sys-devel/gcc-3.3.1-r1. Repoman complains about state and rightly so as the portage tree is currently in an inconsistent state.
sure it's invalid ... in order to properly use nptl you need to be using unstable packages (development-sources, gcc, linux-headers, etc... etc... etc...) file a new bug with portage about supporting 'unstable USE flags' ... changing this bug over to that would carry too much cruft
wouldn't it cause less headaches to have a revision bumped version to support that flag and throw it in to ~arch? meanwhile this regular ebuild in arch simply doesn't support nptl at all. It's kind of inconvenient (looking at the number of people complaining) to have bleeding edge and stable mix in one ebuild as they are here.
since 2.3.3_preXXX is unstable on all archs that 2.3.2-r9 covers and it has nptl support i've removed nptl from 2.3.2-r9 now we shouldnt have people who put nptl into their USE and running a stable x86 complaining their system is broken props to seemant cause he's my dad
*** Bug 40389 has been marked as a duplicate of this bug. ***
i recently compiled glibc-2.3.2-r3 with NPTL support. so why is gcc 3.3 needed for glibc-2.3.2-r9 with NPTL support? i also was abled to compile glibc-2.3.2-r9 with NPTL support by modifying the ebuild. so what's the reason why i should use gcc3.3?
