With the "java" use flag, the deps for protobuf are ">=virtual/jdk-1.5", but it won't emerge with jdk-1.6. Reproducible: Always Steps to Reproduce: 1. Enable the java use flag for protobuf 2. Ebuild protobuf to the compile stage Actual Results: With the "java" flag, protobuf-2.0.3 depends on >=jdk-1.5: /usr/portage/dev-libs/protobuf/protobuf-2.0.3.ebuild: DEPEND="${DEPEND} java? ( >=virtual/jdk-1.5 )" RDEPEND="${RDEPEND} java? ( >=virtual/jre-1.5 )" ... and jdk-1.6 is detected and accepted: host user # ebuild /usr/portage/dev-libs/protobuf/protobuf-2.0.3.ebuild clean compile * protobuf-2.0.3.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking protobuf-2.0.3.tar.bz2 ;-) ... [ ok ] * Using: sun-jdk-1.6 >>> Unpacking source... ... but the package build still requires jdk-1.5 specifically: --- copying google/protobuf/text_format.py -> build/lib/google/protobuf copying google/__init__.py -> build/lib/google javac: invalid source release: 1.5 Usage: javac <options> <source files> where possible options include: -g Generate all debugging info -g:none Generate no debugging info -g:{lines,vars,source} Generate only some debugging info -nowarn Generate no warnings -verbose Output messages about what the compiler is doing -deprecation Output source locations where deprecated APIs are used -classpath <path> Specify where to find user class files -sourcepath <path> Specify where to find input source files -bootclasspath <path> Override location of bootstrap class files -extdirs <dirs> Override location of installed extensions -d <directory> Specify where to place generated class files -encoding <encoding> Specify character encoding used by source files -source <release> Provide source compatibility with specified release -target <release> Generate class files for specific VM version -help Print a synopsis of standard options * * ERROR: dev-libs/protobuf-2.0.3 failed. --- All three protobuf ebuilds in portage have this problem. Expected Results: Clean emerge with jdk-1.6, as it would be with jdk-1.5. (I did not test this package with jdk-1.5.) The short-term end-user fix is to disable the "java" use flag for protobuf. I have tested this with protobuf-2.0.3, and it works. The short-term Gentoo solution is to fix the dependencies to require jdk-1.5 (only). The long-term solution is to have the upstream developers expand their build to detect and use the JDK which is present on the system (if it can). If a certain range of JDK's can't be used, then the Gentoo deps need to reflect that.
Resolving this bug. The problem was investigated on a machine that had recently had the "java" use flag turned on, and many updates (including python) done. Dealing with the other java problems led to the discovery that /usr/bin/run-java-tool was not executable. This was noticed when the antlr emerge tried to use /usr/bin/jar. While looking for bugs related to "java-config" (it owns "run-java-tool"), bug 254648 was discovered. http://bugs.gentoo.org/show_bug.cgi?id=254648 This bug suggests that java-config is affected by python updates. After being re-emerged, run-java-tool was executable, antlr emerged, and so did protobuf. *** This bug has been marked as a duplicate of bug 254648 ***
