internal/compiler/util/WeakHashSetOfCharArray$HashableWeakReference.class] [javac] [wrote /mnt/Dati/Gentoo/tmp/portage/eclipse-sdk-3.1-r1/work/eclipse-sdk-3.1/jdtcoresrc/compiler/org/eclipse/jdt/internal/compiler/util/WeakHashSetOfCharArray.class] [javac] [total 38389ms] [echo] UPDATE ecj.jar BUILD SUCCESSFUL Total time: 53 seconds * Bootstrapping ecj [echo] TARGET: compiler2 [echo] compilerArg -encoding ISO-8859-1 [echo] build compiler org.eclipse.jdt.core.JDTCompilerAdapter BUILD FAILED /mnt/Dati/Gentoo/tmp/portage/eclipse-sdk-3.1-r1/work/eclipse-sdk-3.1/jdtcoresrc/compilejdtcore.xml:47: Compiler Adapter 'org.eclipse.jdt.core.JDTCompilerAdapter' can't be found. Total time: 5 seconds !!! ERROR: dev-util/eclipse-sdk-3.1-r1 failed. !!! Function src_compile, Line 105, Exitcode 1 !!! Failed to bootstrap ecj !!! If you need support, post the topmost build error, NOT this status message.
it expects ant 1.6.5 now, updated the dependency please try again after updating ant
Cannot find JAVA_HOME in config file /etc/env.d/java/22javacc Cannot find JAVA_HOME in config file /etc/env.d/java/22javacc Detected a JDK >= 1.5.0 Cannot find JAVA_HOME in config file /etc/env.d/java/22javacc Detected a JDK >= 1.4.2 >>> Unpacking source... >>> Unpacking eclipse-sourceBuild-srcIncluded-3.1.zip to /var/tmp/portage/eclipse-sdk-3.1-r1/work/eclipse-sdk-3.1 * Applying 06-path-fixups.patch ... [ ok ] * Setting up virtual machine Cannot find JAVA_HOME in config file /etc/env.d/java/22javacc Cannot find JAVA_HOME in config file /etc/env.d/java/22javacc Detected a JDK >= 1.5.0 * Cleaning out prebuilt code * Patching build * Optimizing for Java 1.4 VM * Patching makefiles * Building GNOME VFS support * Building Mozilla embed support * Patching makefiles * Building GNOME VFS support * Building Mozilla embed support >>> Source unpacked. i get red warnings too...is that meaningfull?
I get a conflict between ant-core and ant-tasks while installing eclipse-sdk-3.1-r1: emerge -p eclipse-sdk These are the packages that I would merge, in order: Calculating dependencies ...done! [blocks B ] <dev-java/ant-tasks-1.6.5 (is blocking dev-java/ant-core-1.6.5-r1) [ebuild U ] dev-java/ant-core-1.6.5-r1 [1.6.2-r3] [ebuild U ] dev-java/ant-tasks-1.6.5 [1.6.2-r9] [ebuild U ] dev-java/ant-1.6.5 [1.6.2-r6] [ebuild U ] dev-util/eclipse-sdk-3.1-r1 [3.1]
usualy, but those you can ignore
you have too unmerge ant-tasks first
Thank you for the tip, eclipse 3.1-r1 compiled without a problem.
i close it, as it works for me too.
*** Bug 100119 has been marked as a duplicate of this bug. ***
*** Bug 100176 has been marked as a duplicate of this bug. ***
Works for me, too. Thanks! 1. comment: Anybody got the idea to fix dev/util/eclipse-sdk-3.1-r1.ebuild? DEPEND was still set to ">=dev-java/ant-1.6.2" instead of 1.6.5 about half an hour ago on my mirror. DEPEND="${RDEPEND} !jikes? ( >=virtual/jdk-1.4.2 ) >=dev-java/ant-1.6.2 >=sys-apps/findutils-4.1.7 app-arch/unzip app-arch/zip" 2. comment: Looks like this also works well on my amd64. However, in /etc/portage/package.keywords you need to add dev-java/ant ~amd64 dev-java/ant-core ~amd64 dev-java/ant-tasks ~amd64 since they are all marked unstable (but seem to work well) Anyway, as stated above you need to unmerge ant-tasks before you are able to emerge ant. 3. comment This works well on my system with a parallel installation of sun-jdk-1.5.0.04 and blackdown-1.4.2.02. Since I need Java 1.5.0 in eclipse only (working with JBoss and JBoss-IDE there), I set java-config --set-system-vm=blackdown-jdk-1.4.2.02. Then ant, ant-core and ant-tasks are compiled with this java 1.4.2 JDK. For eclipse installation I switch the system VM with java-config --set-system-vm=sun-jdk-1.5.0.04, env-update, soure /etc/profile and emerge eclipse-sdk. After setting the system VM back to the blackdown-jdk, the "normal" java tree is consistently configured and compiled to run in 1.4. Eclipse is ready to run on a user id configured to use the 1.5 VM with java-config --set-user-vm=sun-jdk-1.5.0.04 and so on. This user works with JBoss-4.0.3RC1 (from the jboss website) and the JBoss Eclipse IDE Tools 1.5M2 (also from the JBoss website). Both, JBoss-4.0.3RC1 and the IDE-Tools 1.5M2 are built to be used with a 1.5 JRE. That works very well, including debugging in JBoss.
I don't understand the comment in #10 about ant. We tried depending on ant-1.6.5 for eclipse-sdk-3.1-r1, but it turns out it wasn't really necessary if we rewrote the ebuild slightly. That is why it depends on 1.6.2 again now. Also, this means you don't have to trick around in /etc/portage to get ant-1.6.5 installed.
(In reply to comment #11) > I don't understand the comment in #10 about ant. We tried depending on ant-1.6.5 > for eclipse-sdk-3.1-r1, but it turns out it wasn't really necessary if we > rewrote the ebuild slightly. That is why it depends on 1.6.2 again now. > > Also, this means you don't have to trick around in /etc/portage to get ant-1.6.5 > installed. Maybe you could post the details of your solution, too. For me this problem looks like a developer is using ant-1.6.5 already but forgot that the ebuild is supposed to depend on ant 1.6.2 only. So it makes sense that you either update ant, etc. to version 1.6.5 or you change whatever is specific to 1.6.5 back to 1.6.2 compatible code. So if you post the details of your solution, too, everybody has the choice which solution to choose. A) upgrade ant to 1.6.5 according to comments #1-#10 B) modify the ebuild according to what you are saying Wonderful! BTW, I was actually hoping a developer with access to the tree would change the eclipse-sdk-3.1-r1 ebuild to depend an ant-1.6.5. ;) This way people still using ant-1.6.2 (at least most of the amd64 systems like mine) don't run into this same error.
Ok it work well with all ant dependancy they need ant-1.6.5 ant-tasks-1.6.5 ant-core-1.6.5 .. after that, no problem anymore please core depndancy for eclipse-3.1-r1 thx for support
A bit more patching has been done and an update to ant-core has been issued. Please resync and remerge if you haven't merged it already.
(In reply to comment #14) > A bit more patching has been done and an update to ant-core has been issued. > Please resync and remerge if you haven't merged it already. Ooooh gee, Karl Trygve, how stupid I am.. I'm so sorry, but I didn't recognize you before. Sorry for the stupid comment above, I didn't intend to argue with you or anything. Just thought you are a "normal" user, too, coming up with a different solution. Sorry, again and thanks a lot for your support!!! But since you will probably read this, let me the chance to add an unrelated hint: From what I read in the forum and tested myself, using java 1.5 to build the tree either fails as soon as you come across Xalan (I actually gave up at that point since it insisted so much to be java 1.1 compatible) or Xerces (didn't check that myself, just read a comment about that, so I don't really know). IMHO there is an interesting development regarding the use of these two packages in Java 1.5. The JBoss people recently came up with a plugin for eclipse-3.1 which is supposed to run in an 1.5 JRE. And, they are actually providing xalan and xerces plugins for eclipse-3.1. Again, both to be used in a Java 1.5 environment. The Xerces version is 2.6.2 and it looks like this is already in the build tree. Concerning xalan, this looks a little bit home made. They call it Xalan_1.5.0.M2, where 1.5.0.M2 is the serial of the JBoss-IDE for eclipse running in a Java 1.5.0 environment. Maybe it's worth to take a look at it. They provide xalan.jar, xercesImpl.jar and xml-apis.jar in this xalan package. So if xalan really turns out to be a major problem to switch to a system wide Java 1.5 in Gentoo, it may be worth to consider building a kind of xalan-bin from the Jboss xalan plugin. At least in their case it does the compatiblity trick with Java 1.5. In case you are interested: http://prdownloads.sourceforge.net/jboss/JBossIDE-1.5M2-ALL%2BEJB3.zip?download
Thanks for the tip. With respects to system-wide support for 1.5, we're almost there. The code is in axxo's overlay (https://gentooexperimental.org/svn/java/axxo-overlay/), but it will take a bit more testing before we're certain that it works well enough to be put into the main tree.
