java-devel October 2006

java-devel@lists.fedoraproject.org

9 participants
7 discussions

ld doesn't know about location of libjvm
by Braden McDaniel 06 Nov '06

06 Nov '06

ld seems not to know about /usr/lib[64]/gcj-4.1.1; and as such cannot find libjvm.so without a -L flag. Is this deliberate or a bug? Braden

4 10

making eclipse multilib compatible (bug # 207016)
by Benjamin Konrath 24 Oct '06

24 Oct '06

Hi Andrew, Last week I started looking into making our eclipse packages mulitlib compatible to solve bug # 207016 and I thought I'd write up a little status report of what I found. Here are the issues we need sort out: 1) Ensure the src zips are the same for all arches 2) Put the native fragments in %{_libdir} - the swt classes need to go there too because they use 32-bit or 64-bit references depending on the arch 3) Ensure that configuration will work when the user has different 32-bit features and 64-bit features installed (e.g. 32-bit platform and jdt with 64-bit platform, jdt and pde) Solutions: 1) ensuring the src zips are the same for all arches ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Repack all the zips at the end of the build similar to how the brp script repacks all jars OR - Make the non-arch dependent packages noarch so that the src zips will come from same package on all arches. IIRC the kernel has a hack to do this for its doc package 2) Putting native code in %{_libdir} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This site explains how to configure eclipse to put features and plugins in separate directories: http://www-128.ibm.com/developerworks/opensource/library/os-ecl-manage/ The only method that works for SWT is the one that requires the user to add an extension location in the configuration manager. Obviously this is not useful for a build, but we may be able to take the configuration it adds to configuration/org.eclipse.update/platform.xml and insert it in the build. With this we will need to have configuration/org.eclipse.update/platform.xml and we cannot remove like we have been planning. So we can either use the rebuild features script again or we can run the file initializer with an empty configuration every time an eclipse package is installed. For the file initializer solution I'm not sure if this will preserve section of platform.xml that specifies the separate location of the native fragments. I still need to test this out. As far as using the rebuild features script again, we have already seen that using it is not really maintainable because it's difficult to know what format the platform.xml file needs to be in. Also, we shouldn't create procedures that require us to maintain code outside of the upstream code. We already spend most of our time packaging stuff and don't have time to respond to real bug reports in a timely manner. Adding this again would just tie us up even more and would be a bad decision IMHO. But if there's no other method that will work, then we have no choice. 3) Working with different 32 and 64 bit features ================================================ We will need to drop the sed logic that changes configuration/config.ini and always run with eclipse.product=org.eclipse.platfrom.ide or eclipse.product=org.eclipse.sdk.ide because both the 64-bit packages and the 32-bit packages will change that config entry. If the two sets of packages get out of sync, this will be set incorrectly. The solutions for problem 2 might might also cause problems here if the packages get out of sync. Here's an example: If a user has both the 32-bit eclipse-sdk and the 64-bit eclipse-sdk package installed and then removes the 64-bit eclipse-sdk and eclipse-pde, the 32-bit eclispe-sdk and 32-bit eclipse-pde will not be removed and the pre-configuration will not be set correctly because the packages share configuration directory. I think this would be a problem for both the rebuild features script and the file initializer solution. I don't really have a solution for this problem. Andrew, do you have any thoughts? If we could specify a different configuration directory, we would be able to get around this, but I haven't run across any way to do this yet. Ok, that's all I have for now. I'll continue working on this. Ben

3 7

Fedora Eclipse Live CD
by Andrew Overholt 11 Oct '06

11 Oct '06

Vvvvt! I'm not on fedora-desktop-list so I missed this but it looks very cool: https://www.redhat.com/archives/fedora-desktop-list/2006-September/msg00043… Ben, this could probably super-cede the work you did on the Eclipse live CD back in March. Andrew

1 0

gjdoc regression?
by Anthony Green 06 Oct '06

06 Oct '06

kawa fails to build in rawhide now with the following error (while building javadocs)... java.lang.reflect.InvocationTargetException at java.lang.reflect.Method.invoke(libgcj.so.7rh) at gnu.classpath.tools.gjdoc.Main.startDoclet(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.gjdoc.Main.start(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.gjdoc.Main.main(gnu-classpath-tools-gjdoc-0.7.7.jar.so) Caused by: java.lang.NoClassDefFoundError: gnu.classpath.tools.gjdoc.expr.Evaluator at java.lang.Class.initializeClass(libgcj.so.7rh) at gnu.classpath.tools.gjdoc.FieldDocImpl.constantValue(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.gjdoc.FieldDocImpl.constantValue(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.doclets.htmldoclet.HtmlDoclet.printMemberDetails(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.doclets.htmldoclet.HtmlDoclet.printClassPage(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.doclets.htmldoclet.HtmlDoclet.run(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.doclets.AbstractDoclet.startInstance(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at gnu.classpath.tools.doclets.AbstractDoclet.start(gnu-classpath-tools-gjdoc-0.7.7.jar.so) at java.lang.reflect.Method.invoke(libgcj.so.7rh) ...3 more Caused by: java.lang.ClassNotFoundException: antlr.CharScanner not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/java/com-sun-javadoc-0.7.7.jar,file:/usr/share/java/com-sun-tools-doclets-Taglet-0.7.7.jar,file:/usr/share/java/gnu-classpath-tools-gjdoc-0.7.7.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(libgcj.so.7rh) at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.VMClassLoader.defineClass(libgcj.so.7rh) at java.lang.ClassLoader.defineClass(libgcj.so.7rh) at java.security.SecureClassLoader.defineClass(libgcj.so.7rh) at java.net.URLClassLoader.findClass(libgcj.so.7rh) at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.ClassLoader.loadClass(libgcj.so.7rh) at java.lang.Class.initializeClass(libgcj.so.7rh) ...11 more make: *** [install-javadoc-html] Error 5 I'm hoping that adding antlr to the classpath somewhere will fix this. Is this a known regression? AG

5 7

tutorial for debugging Eclipse GCJ problems
by Benjamin Konrath 03 Oct '06

03 Oct '06

Hi, I wrote up a little tutorial on how get yourself setup to track down Eclipse GCJ problems: http://wiki.eclipse.org/index.php/Debugging_Eclipse_GCJ_Problems Please feel free to add to it and / or correct any errors that might be present. Also, if you have any questions, feel free to drop me a line. Cheers, Ben

1 0

3.2.1 Eclipse SDK Tests on FC6
by Andrew Overholt 03 Oct '06

03 Oct '06

Hi, I ran the 3.2.1 automated tests on my laptop (running what will become Fedora Core 6) this morning. I had to comment out a few due to failures that were taking forever to hit the timeout: update antui Also, I didn't run the following: jdtdebug (no complete JDWP in gij yet) relEng (I wasn't interested ... I may be wrong) jdtapt (no complete 1.5 in libgcj/gij yet) I've put the results of the ones that did run here: 3.2.1 on x86 (with gcj, obviously): http://www.overholt.ca/eclipse/testresults/20061003/ and the log (lots of exceptions we need to track down and I think I may have truncated bits of this accidentally; ~26 MB log): http://www.overholt.ca/eclipse/testresults/20061003/20061003.log Note that there are still a few tests which I have to patch to not try to write to /usr/share/eclipse. Also, some of the errors are due to missing environment properties set (ie. MOZILLA_FIVE_HOME). Over time, I hope we will be able to track down all of these failures and get to the point where we get 100% on all tests. Note that I still had to apply a few patches to the tests to get them to run against the installed (RPM) Eclipse SDK (Fedora Eclipse) and to not write to /usr/share/eclipse. I'm going to submit these upstream -- those that make sense, at least -- so we can hopefully run the 3.3 tests with few -- if any -- patches. HTH, Andrew

1 0

Eclipse startup time
by Andrew Overholt 02 Oct '06

02 Oct '06

In some *completely* unscientific tests, I've found that on my laptop, my large-ish workspace starts up in around 19 seconds with stock rawhide (gcj) and in around 16 seconds with the Sun JDK. This is completely unverifiable and unreproducable but I just thought I'd send out the mad props to the gcj, Classpath, and toolchain teams for their great work in speed improvements. Keep up the great work! Andrew

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel October 2006