Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 204998 - Sun Java depends on libstdc-3.3
Summary: Sun Java depends on libstdc-3.3
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo non-Linux Team
Depends on:
Reported: 2008-01-09 08:12 UTC by Rabbe Fogelholm
Modified: 2008-01-19 15:34 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Rabbe Fogelholm 2008-01-09 08:12:46 UTC
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/ blib/lib/XML/Parser/Style/
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/ blib/lib/XML/Parser/Style/
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/ blib/lib/XML/Parser/
cp Parser/Style/ blib/lib/XML/Parser/Style/
cp blib/lib/XML/
cp Parser/Style/ blib/lib/XML/Parser/Style/
cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc
cp Parser/Style/ blib/lib/XML/Parser/Style/
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
cp ../blib/lib/XML/Parser/
/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
make: *** [subdirs] Error 2
 * ERROR: dev-perl/XML-Parser-2.34-r1 failed.
 * Call stack:
 *     , 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
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2008-01-09 08:51:08 UTC
You are using gcc-3.3.x which is unsupported.
Comment 2 Fabian Groffen gentoo-dev 2008-01-09 09:19:01 UTC
Ahh... so I guess this must be during bootstrapping with the host provided gcc?

What is pulling in XML-Parser?
Comment 3 Rabbe Fogelholm 2008-01-09 16:40:40 UTC
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

That looks weird, "Gentoo 3.3.6".

I enclose `emerge --info' output for now, will inspect the bootstrapping log too later.

Portage (default-prefix/linux/x86, gcc-3.3.6, unavailable, i686)
System uname: 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/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.24
ACCEPT_KEYWORDS="~x86 ~x86-linux"
CFLAGS="-O2 -pipe"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -pipe"
FEATURES="collision-protect distlocks metadata-transfer preserve-libs sandbox sfperms strict unmerge-orphans userfetch"
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-*"
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"

Comment 4 Fabian Groffen gentoo-dev 2008-01-09 17:39:01 UTC
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.
Comment 5 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-01-09 19:11:42 UTC
(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?
Comment 6 Rabbe Fogelholm 2008-01-09 19:28:32 UTC
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
Comment 7 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-01-09 19:51:24 UTC
(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.
Comment 8 Fabian Groffen gentoo-dev 2008-01-09 19:52:41 UTC
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.
Comment 9 Fabian Groffen gentoo-dev 2008-01-09 19:53:53 UTC
(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.
Comment 10 Fabian Groffen gentoo-dev 2008-01-09 19:54:54 UTC
... 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).
Comment 11 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-01-09 20:20:47 UTC
(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 ;-)

Comment 12 Fabian Groffen gentoo-dev 2008-01-09 20:47:42 UTC
> 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?
Comment 13 Rabbe Fogelholm 2008-01-09 21:49:57 UTC
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?
Comment 14 Fabian Groffen gentoo-dev 2008-01-09 21:58:03 UTC
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.
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2008-01-09 22:26:01 UTC
(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.
Comment 16 Fabian Groffen gentoo-dev 2008-01-11 12:03:38 UTC
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!
Comment 17 Rabbe Fogelholm 2008-01-12 15:00:04 UTC
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])
Comment 18 Fabian Groffen gentoo-dev 2008-01-19 15:34:33 UTC
sun java now no longer depends on libstdc-3.3 for prefix, which should totally fix any trail of problems shown in this bug.