XML-Parser-2.34-r1 cannot be emerged. The console output looks like this, $ emerge XML-Parser Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) dev-perl/XML-Parser-2.34-r1 to / * XML-Parser-2.34.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking XML-Parser-2.34.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking XML-Parser-2.34.tar.gz to /local/scratch/portage/dev-perl/XML-Parser-2.34-r1/work >>> Source unpacked. >>> Compiling source in /local/scratch/portage/dev-perl/XML-Parser-2.34-r1/work/XML-Parser-2.34 ... * Using ExtUtils::MakeMaker Checking if your kit is complete... Looks good Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Style/Tree.pm blib/lib/XML/Parser/Style/Tree.pm cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/windows-1252.enc blib/lib/XML/Parser/Encodings/windows-1252.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Style/Subs.pm blib/lib/XML/Parser/Style/Subs.pm cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Parser/Style/Objects.pm blib/lib/XML/Parser/Style/Objects.pm cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Style/Debug.pm blib/lib/XML/Parser/Style/Debug.pm cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser/Style/Stream.pm blib/lib/XML/Parser/Style/Stream.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc make[1]: Entering directory `/local/scratch/portage/dev-perl/XML-Parser-2.34-r1/work/XML-Parser-2.34/Exp at' cp Expat.pm ../blib/lib/XML/Parser/Expat.pm /local/scratch/nightly/2008-01-09/usr/bin/perl5.8.8 /local/scratch/nightly/2008-01-09/usr/lib/perl5/5.8. 8/ExtUtils/xsubpp -noprototypes -typemap /local/tmp/nightly/2008-01-09/usr/lib/perl5/5.8.8/ExtUtils/type map -typemap typemap Expat.xs > Expat.xsc && mv Expat.xsc Expat.c i686-pc-linux-gnu-gcc -c -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/local/tmp/nightly /2008-01-09/usr/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -pipe -DVERSION=\"2.34\" -DXS_V ERSION=\"2.34\" -fPIC "-I/local/tmp/nightly/2008-01-09/usr/lib/perl5/5.8.8/i686-linux/CORE" Expat.c cc1: error: unrecognized option `-Wdeclaration-after-statement' make[1]: *** [Expat.o] Error 1 make[1]: Leaving directory `/local/scratch/portage/dev-perl/XML-Parser-2.34-r1/work/XML-Parser-2.34/Expa t' make: *** [subdirs] Error 2 * * ERROR: dev-perl/XML-Parser-2.34-r1 failed. * Call stack: * ebuild.sh, line 46: Called src_compile * environment, line 2437: Called perl-module_src_compile * environment, line 2179: Called die * The specific snippet of code: * make ${mymake} || diefunc "$FUNCNAME" "$LINENO" "$?" "compilation failed"; * The die message: * compilation failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/local/scratch/portage/dev-perl/XML-Parser-2.34-r1/temp/build.log '. * The ebuild environment file is located at '/local/scratch/portage/dev-perl/XML-Parser-2.34-r1/temp/en vironment'. *
You are using gcc-3.3.x which is unsupported.
Ahh... so I guess this must be during bootstrapping with the host provided gcc? What is pulling in XML-Parser?
Hmm ... I am confused. I was trying to emerge gkrellm, which pulls in 20+ packages. When running a shell in the prefix I get > which gcc /local/tmp/nightly/2008-01-09/usr/bin/gcc (looks ok) > gcc --version gcc (GCC) 3.3.6 (Gentoo 3.3.6-r1 p1.5, ssp-3.3.6-1.0, pie-8.7.8) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. That looks weird, "Gentoo 3.3.6". I enclose `emerge --info' output for now, will inspect the bootstrapping log too later. Portage 2.2.00.9154-prefix (default-prefix/linux/x86, gcc-3.3.6, unavailable, 2.6.16.53-0.16-smp i686) ================================================================= System uname: 2.6.16.53-0.16-smp i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Timestamp of tree: Wed, 09 Jan 2008 01:56:14 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.3-r00.1 dev-lang/python: 2.5.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r01.1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18.50.0.3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 ACCEPT_KEYWORDS="~x86 ~x86-linux" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/local/tmp/nightly/2008-01-09/usr/portage/distfiles" EPREFIX="/local/tmp/nightly/2008-01-09" FEATURES="collision-protect distlocks metadata-transfer preserve-libs sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.gentoo.no/ http://mirror.qubenet.net/mirror/gentoo/ http://mirror.muntinternet.net/pub/gentoo/ http://ftp.linux.ee/pub/gentoo/distfiles/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="en_US" PKGDIR="/local/tmp/nightly/2008-01-09/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/local/scratch" PORTDIR="/local/tmp/nightly/2008-01-09/usr/portage" SYNC="svn+http://overlays.gentoo.org/svn/proj/alt/trunk/prefix-overlay" USE="X cracklib iconv midi mudflap ncurses nls openmp prefix readline ssl unicode x86 zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
this may be related to my keywords screwup. Even though ACCEPT_KEYWORDS="~x86 ~x86-linux" looks good, maybe for some reason gcc-4* are masked.
(In reply to comment #4) > this may be related to my keywords screwup. Even though ACCEPT_KEYWORDS="~x86 > ~x86-linux" looks good, maybe for some reason gcc-4* are masked. No, its fine for me. @Rabbe, what is the output of "emerge -p gcc". Does it want to upgrade?
It goes like this, > emerge -p gcc ... [ebuild R ] sys-devel/gcc-4.2.2 This is consistent with the fact that gcc-4.2.2 was emerged according to the bootstrapping console log (twice, once for each `emerge -e' command). However, I also notice this: > gcc-config -B /local/tmp/nightly/2008-01-09/usr/i686-pc-linux-gnu/gcc-bin/3.3.6
(In reply to comment #6) > > gcc-config -B > /local/tmp/nightly/2008-01-09/usr/i686-pc-linux-gnu/gcc-bin/3.3.6 Bingo, you are using gcc 3.3.6. Use gcc-config to switch your gcc "profile" "gcc-config -l" to list the gcc's "gcc-config <#>" where # is the gcc you want to use. "which gcc" isn't a very good indicator of what gcc you are using because gcc is just a symlink, do a ls -l on that path to see what version it is using too.
what does gcc-config -l show? I recall (but didn't care to pay too much attention -- thought it was an issue due to various hacks) that gcc-config for some reason wouldn't update to the latest compiler. But in any case, I don't understand how it ended up installing 3.3.6 during bootstrap.
(In reply to comment #7) > "which gcc" isn't a very good indicator of what gcc you are using because gcc > is just a symlink, do a ls -l on that path to see what version it is using too. No. The gcc wrapper does an optimistic path lookup, and if that fails, a call to binutils-config to figure out where it is. If that fails as well, it exits with an error.
... and because it does a path lookup, the gcc being found is dependant on your path. That's why gcc-config tells you to source /etc/profile (to get the correct path).
(In reply to comment #8) > what does gcc-config -l show? -l, --list-profiles Print a list of available profiles. (In reply to comment #9) > No. The gcc wrapper does an optimistic path lookup, and if that fails, a call Yes, sorry. I was thinking of the symlink that exists in usr/$CHOST/gcc-bin dir, excuse my oversight. -- I'm not sure why gcc-3.3.6 was pulled in but if he already emerged 4.*, that is the problem here, he didn't select the correct profile. Case closed ;-)
> I'm not sure why gcc-3.3.6 was pulled in but if he already emerged 4.*, that is > the problem here, he didn't select the correct profile. Case closed ;-) Defenitely not. Two problems: 1. gcc-3.3.6 is only there for the compiler freaks (me), so shouldn't have been pulled in (borkened depgraph, libffi or something?) 2. why doesn't gcc-config switch itself any more?
Hi all, here is more info, > gcc-config -l [1] i686-pc-linux-gnu-3.3.6 * [2] i686-pc-linux-gnu-4.2.2 I also see that `emerge sun-jdk', which I did before `emerge gkrellm', pulls in gcc-3.3.6-r1. And indeed, close to the end of that emerge, * Switching native-compiler to i686-pc-linux-gnu-3.3.6 ... Does this mean that I should simply switch to gcc-3.3.6-* if/when working in the Java domain, and back to gcc-4.* at other times?
this feels like you hit a problem with the java stuff. They probably force the compiler down to 3.3.6, which causes trouble lateron. Switch it back. You don't need gcc-3.3.6 enabled when working with Java. I don't recall having it on my machine, but I had 3.3.6 already installed for sure... Anyway, this is not something I can fix, as this is a more general problem.
(In reply to comment #12) > 2. why doesn't gcc-config switch itself any more? Well, it never did in gentoo-x86 since it can cause heavy borkage when the ABI changes. As for why's it getting pulled in, simply because it's how virtual/libstdc++ is handled by portage, it will prefer gcc over libstdc++-v3 because you have that already installed. And no, Java does *not* switch to gcc-3.3.6, it's simply that it gets pulled in for that virtual. To prevent this from happening, you should drop all keywords from gcc-3.3.6, mask it or remove it from the virtual.
I see, in the main tree gcc-3.3.6 is ~arch, where as for us everything is ~arch, so will mask it. Thanks jakub!
Does this mean that right now there is no (easy) way to emerge sun-jdk? I tried `emerge sun-jdk' in a freshly bootstrapped prefix and got erarafo@ws4941 /local/tmp/nightly/2008-01-12 $ emerge sun-jdk emerge: there are no ebuilds to satisfy "=sys-libs/libstdc++-v3-bin-3.3*". (dependency required by "virtual/libstdc++-3.3" [ebuild])
sun java now no longer depends on libstdc-3.3 for prefix, which should totally fix any trail of problems shown in this bug.
