making eclipse multilib compatible (bug # 207016)
by Benjamin Konrath
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
17 years, 1 month
gjdoc regression?
by Anthony Green
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
17 years, 2 months
3.2.1 Eclipse SDK Tests on FC6
by Andrew Overholt
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
17 years, 2 months
Eclipse startup time
by Andrew Overholt
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
17 years, 2 months
