aot-compile-rpm problem
by Anthony Green
Hi,
On rawhide, when I do a "yum install java-1.4.2-gcj-compat-devel" on my
x86-64 system I get both the x86-64 and x86 packages. I suppose the x86
version is written last, because aot-compile-rpm's LIBDIR is set
to /usr/lib/gcj instead of /usr/lib64/gcj. This pretty much breaks rpm
building.
The fix is to make sure I just "yum install
java-1.4.2-gcj-compat-devel.x86_64".
Is this expected behaviour? I don't remember this being a problem for
my in the past.
Thanks,
AG
17 years, 9 months
Re: ssl connections, cacerts
by Anthony Green
On Mon, 2006-07-31 at 13:24 -0700, Casey Marshall wrote:
> Most GNU/Linux distributions have packages for a list of root
> certificates, usually as just a bunch of separate PEM files. Does
> Fedora have something like that?
Yes. It looks like openssl ships with certificates. kdelibs does as
well. Perhaps there are others.
> If so, one good way to fix this
> would be to generate a cacerts file (using gkeytool) that contains
> the same list of certificates, and add that to the GCJ RPM. It is
> somewhat preferable for distributions to figure out which root
> certificates they want to use, than for Classpath to arbitrarily
> decide what certificates to include, IMO.
Sounds good. This should probably go in the java-1.4.2-gcj-compat
package (our JDK compatibility layer on top of gcj). We could simply
"BuildRequire" openssl to generate and package the cacerts files.
> Does that make sense? I can explain how to generate such a cacerts
> file from a bunch of separate certificates, if you like.
That would be great. I've never run gkeytool before.
> Additionally, loading cacerts isn't even necessary with Classpath:
> Jessie uses an internal list of root certificates (approximately the
> same list you'll find by default in e.g. Firefox) if no other
> certificates are provided. Nice to see that the RSSOwl people had to
> make this crap so "Easy." A bug (or maybe just some harsh words)
> upstream is also advisable.
Ok.
Thanks,
AG
17 years, 9 months
gcjwebplugin has landed in Rawhide
by Thomas Fitzsimmons
Hi,
gcc-4.1.1-12, which contains libgcjwebplugin.so, went into Rawhide last night
along with java-1.4.2-gcj-compat-plugin which installs an alternatives-managed
"libjavaplugin.so" symlink in /usr/lib/mozilla/plugins.
I closed the long-standing "Inclusion of gcjwebplugin" bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127537
and updated the release notes with a "Handling Java Applets" section:
http://fedoraproject.org/wiki/Docs/Beats/Java
Rawhide users can install gcjwebplugin with "yum install
java-1.4.2-gcj-compat-plugin". Please try this out, file bugs and comment on
the release note additions.
The GNU Classpath AWT and Swing code was in a state of flux when the backport
that included gcjwebplugin was done (because of a large Java2D rewrite to make
the Cairo backend the default), so there are some regressions in AWT and Swing
applications for FC6test2.
My post-test2 plan for gcjwebplugin is to gage the reaction of Rawhide users,
and also to do another GUI backport from GNU Classpath HEAD to Fedora's libgcj,
to fix the AWT and Swing regressions. If the reaction turns out to be overly
negative, even after the new AWT and Swing backport, we can always make
gcjwebplugin not installed by default, for FC6test3. For FC6test2 though, it is
installed by default if the Internet group is selected.
Tom
17 years, 9 months
fc6 extras java status
by Anthony Green
Things are a little ugly in fc6 extras java land...
* Azureus makes my computer practically unusable because of libgcj's new
SecureRandom implementation. I've filed a bug for a work around here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200653
Mark tells me this is the root cause of some crypto test timeout
problems on the autobuilder as well. Casey says that this same code
doesn't seem to have a problem on jamvm.
* RSSOwl no longer fails to start because of the zip problem (thanks
tromey!), but now crashes in _Jv_ClassReader::checkExtends (super =
0x3). I'm rebuilding libgcj with -O0 -g3 to debug.
* I've updated jogl to jsr231 1.0 beta 5. The good news is that it
builds sans patching! The bad news is that demos crash the X server
(like, try resizing the gears demo). I think this is an X problem, so
I'm going to push this out anyways because the latest WW2D (and "WW2D
plus one", which looks awesome --
http://www.alpix.com/3d/worldwin/WW2d_Java.html) use this version of the
jogl API.
* kawa is fine.
AG
17 years, 9 months
gnu-crypto & jessie
by Anthony Green
Do we still need these packages in fc6 or did they get merged into
libgcj? Anybody know?
Thanks,
AG
17 years, 9 months
ssl connections, cacerts
by Anthony Green
Now that rssowl is running (thanks aph), I wanted to see if https rss
feeds would work (like those provided by bugzilla).
Our classpath.security file is messed up, but I think fitzsim just fixed
this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200701
When I fix it manually, and try to access an https rss feed, I get...
Exception in thread "Load Feed Thread" org.apache.commons.httpclient.HttpClientError: java.security.KeyStoreException: java.io.FileNotFoundException: /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/security/cacerts (No such file or directory)
at net.sourceforge.rssowl.dao.ssl.EasySSLProtocolSocketFactory.createEasySSLContext(Unknown Source)
at net.sourceforge.rssowl.dao.ssl.EasySSLProtocolSocketFactory.getSSLContext(Unknown Source)
at net.sourceforge.rssowl.dao.ssl.EasySSLProtocolSocketFactory.createSocket(Unknown Source)
at org.apache.commons.httpclient.HttpConnection.open(jakarta-commons-httpclient-3.0.jar.so)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(jakarta-commons-httpclient-3.0.jar.so)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(jakarta-commons-httpclient-3.0.jar.so)
at org.apache.commons.httpclient.HttpClient.executeMethod(jakarta-commons-httpclient-3.0.jar.so)
at org.apache.commons.httpclient.HttpClient.executeMethod(jakarta-commons-httpclient-3.0.jar.so)
at net.sourceforge.rssowl.dao.ConnectionManager.openConnection(Unknown Source)
at net.sourceforge.rssowl.dao.ConnectionManager.connect(Unknown Source)
at net.sourceforge.rssowl.dao.ConnectionManager.connect(Unknown Source)
at net.sourceforge.rssowl.dao.NewsfeedFactory.initXmlDocument(Unknown Source)
at net.sourceforge.rssowl.dao.NewsfeedFactory.<init>(Unknown Source)
at net.sourceforge.rssowl.dao.NewsfeedFactory.<init>(Unknown Source)
at net.sourceforge.rssowl.controller.thread.FeedLoader.run(Unknown Source)
We don't have a cacerts file. How is this supposed to work?
AG
17 years, 9 months
[poohba@blkpoohba.dyndns.org: Getting java errors when trying to install limewire]
by Andrew Overholt
See below from fedora-list.
We don't expect limewire to work with what I'm assuming is FC5, right? Has
anyone tried it with rawhide?
Andrew
----- Forwarded message from Poohba <poohba(a)blkpoohba.dyndns.org> -----
> From: Poohba <poohba(a)blkpoohba.dyndns.org>
> To: For users of Fedora Core releases <fedora-list(a)redhat.com>
> X-Mailer: Evolution 2.6.0 (2.6.0-1)
> Date: Tue, 25 Jul 2006 20:10:20 -0400
> Subject: Getting java errors when trying to install limewire
>
> Is this because I don't have the correct or all of the java's needed?
>
> ./LimeWireLinux.bin
> Preparing to install...
> Extracting the installation resources from the installer archive...
> Configuring the installer for this system's environment...
>
> Launching installer...
>
> Exception in thread "main" java.lang.NoClassDefFoundError:
> com.zerog.lax.LAX
> at gnu.java.lang.MainThread.run (libgcj.so.7)
> Caused by: java.lang.ClassNotFoundException: com.zerog.lax.LAX not found
> in
> gnu.gcj.runtime.SystemClassLoader{urls=[file:/tmp/install.dir.14630/InstallerData/,file:/tmp/install.dir.14630/InstallerData/installer.zip], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> at java.net.URLClassLoader.findClass (libgcj.so.7)
> at java.lang.ClassLoader.loadClass (libgcj.so.7)
> at java.lang.ClassLoader.loadClass (libgcj.so.7)
> at java.lang.Class.forName (libgcj.so.7)
> at gnu.java.lang.MainThread.run (libgcj.so.7)
>
>
> yum install java*
> Loading "installonlyn" plugin
> Setting up Install Process
> Setting up repositories
> core
> [1/3]
> extras
> [2/3]
> updates
> [3/3]
> Reading repository metadata in from local files
> Parsing package install arguments
> Resolving Dependencies
> --> Populating transaction set with selected packages. Please wait.
> ---> Downloading header for javacc-demo to pack into transaction set.
> javacc-demo-3.2-1jpp_6fc. 100% |=========================| 20 kB
> 01:33
> ---> Package javacc-demo.i386 0:3.2-1jpp_6fc set to be updated
> ---> Downloading header for java-clearsilver to pack into transaction
> set.
> ftp://mirror.newnanutilities.org/pub/fedora/linux/extras/5/i386/java-clea...: [Errno 4] IOError: [Errno ftp error] (111, 'Connection refused')
> Trying other mirror.
> java-clearsilver-0.10.3-3 100% |=========================| 3.8 kB
> 00:00
> ---> Package java-clearsilver.i386 0:0.10.3-3.fc5 set to be updated
> ---> Downloading header for javacc to pack into transaction set.
> ftp://ftp.tecnoera.com/pub/fedora/linux/core/5/i386/os/Fedora/RPMS/javacc...: [Errno 4] IOError: [Errno ftp error] timed out
> Trying other mirror.
> javacc-3.2-1jpp_6fc.i386. 100% |=========================| 4.9 kB
> 00:00
> ---> Package javacc.i386 0:3.2-1jpp_6fc set to be updated
> ---> Downloading header for java-1.4.2-gcj-compat-javadoc to pack into
> transaction set.
> java-1.4.2-gcj-compat-jav 100% |=========================| 887 kB
> 00:01
> ---> Package java-1.4.2-gcj-compat-javadoc.i386 0:1.4.2.0-40jpp_83rh set
> to be updated
> ---> Downloading header for javacc-manual to pack into transaction set.
> javacc-manual-3.2-1jpp_6f 100% |=========================| 5.6 kB
> 00:00
> ---> Package javacc-manual.i386 0:3.2-1jpp_6fc set to be updated
> --> Running transaction check
>
> Dependencies Resolved
>
> =============================================================================
> Package Arch Version Repository
> Size
> =============================================================================
> Installing:
> java-1.4.2-gcj-compat-javadoc i386 1.4.2.0-40jpp_83rh core 21
> M
> java-clearsilver i386 0.10.3-3.fc5 extras
> 85 k
> javacc i386 3.2-1jpp_6fc core
> 915 k
> javacc-demo i386 3.2-1jpp_6fc core
> 95 k
> javacc-manual i386 3.2-1jpp_6fc core
> 76 k
>
> Transaction Summary
> =============================================================================
> Install 5 Package(s)
> Update 0 Package(s)
> Remove 0 Package(s)
> Total download size: 22 M
> Is this ok [y/N]: y
> Downloading Packages:
> (1/5): javacc-demo-3.2-1j 100% |=========================| 95 kB
> 00:00
> (2/5): java-clearsilver-0 100% |=========================| 85 kB
> 00:00
> (3/5): javacc-3.2-1jpp_6f 100% |=========================| 915 kB
> 00:03
> (4/5): java-1.4.2-gcj-com 100% |=========================| 21 MB
> 00:18
> (5/5): javacc-manual-3.2- 100% |=========================| 76 kB
> 00:00
> warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID
> 1ac70ce6
> Public key for java-clearsilver-0.10.3-3.fc5.i386.rpm is not installed
> Retrieving GPG key from
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras
> Importing GPG key 0x1AC70CE6 "Fedora Project
> <fedora-extras(a)fedoraproject.org>"
> Is this ok [y/N]: y
> Key imported successfully
> Running Transaction Test
> Finished Transaction Test
> Transaction Test Succeeded
> Running Transaction
> Installing: javacc-manual #########################
> [1/5]
> Installing: javacc-demo #########################
> [2/5]
> Installing: java-clearsilver #########################
> [3/5]
> Installing: javacc #########################
> [4/5]
> Installing: java-1.4.2-gcj-compat-javado #########################
> [5/5]
>
> Installed: java-1.4.2-gcj-compat-javadoc.i386 0:1.4.2.0-40jpp_83rh
> java-clearsilver.i386 0:0.10.3-3.fc5 javacc.i386 0:3.2-1jpp_6fc
> javacc-demo.i386 0:3.2-1jpp_6fc javacc-manual.i386 0:3.2-1jpp_6fc
> Complete!
>
>
>
> --
> fedora-list mailing list
> fedora-list(a)redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
----- End forwarded message -----
17 years, 9 months
Regression in libgcj: spurious IncompatibleClassChangeError with BC-compiled code.
by Andrew Haley
This happens if a class and its superclass are loaded by the boot
classloader. If one if them is in the precompiled database and one
isn't, we fail this check:
if ( sub->loader != super->loader
|| !_Jv_ClassNameSamePackage (sub->name, super->name))
{
throw_incompatible_class_change_error (sub->getName ());
}
We fail this check becasue of this line in natVMClassLoader.cc
// Record the defining loader. For the bootstrap class loader,
// we record NULL.
if (loader != bootLoader)
klass->loader = loader;
So, at the point of this test:
sub->loader != super->loader
sub->loader == bootLoader, and super->loader == NULL.
All this happens because when a class is loaded by natSharedLibLoader,
we do this:
void
_Jv_sharedlib_register_hook (jclass cls)
{
cls->protectionDomain = curHelper->domain;
cls->loader = curLoader;
if (! cls->engine)
cls->engine = &_Jv_soleCompiledEngine;
curHelper->registerClass(cls->getName(), cls);
}
note that we always set the loader; we don't check for it being the
bootLoader.
There are several ways to fix this. We need it for FC6.
Andrew.
2006-07-25 Andrew Haley <aph(a)redhat.com>
* gnu/gcj/runtime/natSharedLibLoader.cc (init): Don't set
curLoader to VMClassLoader::bootLoader.
--- natSharedLibLoader.cc~ 2006-07-25 16:47:05.000000000 +0100
+++ natSharedLibLoader.cc 2006-07-25 18:11:25.000000000 +0100
@@ -20,6 +20,8 @@
#include <java/lang/UnsupportedOperationException.h>
#include <java/lang/UnknownError.h>
+#include <java/lang/VMClassLoader.h>
+
// If we're using the Boehm GC, then we need this include to override dlopen.
#ifdef HAVE_BOEHM_GC
// Set GC_DEBUG before including gc.h!
@@ -87,7 +89,8 @@
flags = RTLD_GLOBAL | RTLD_LAZY;
JvSynchronize dummy1(&java::lang::Class::class$);
SharedLibDummy dummy2;
- curLoader = loader;
+ curLoader = ((void*)loader == java::lang::VMClassLoader::bootLoader
+ ? NULL : loader);
curHelper = this;
_Jv_RegisterClassHook = _Jv_sharedlib_register_hook;
_Jv_RegisterCoreHook = core_hook;
17 years, 10 months
CDT hover error
by Andrew Overholt
Hi Jeff,
With the latest autotools work you've done (in eclipse-cdt in rawhide),
I can't seem to get hover help working. I get this in
<workspace>/.metadata/.log:
!ENTRY org.eclipse.cdt.ui 4 2 2006-07-24 14:18:24.831
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.cdt.ui".
!STACK 0
java.lang.NullPointerException
at org.eclipse.core.internal.runtime.Activator.getURLConverter(org.eclipse.equinox.common_3.2.0.v20060603.jar.so)
at org.eclipse.core.runtime.FileLocator.toFileURL(org.eclipse.equinox.common_3.2.0.v20060603.jar.so)
at org.eclipse.core.runtime.Platform.asLocalURL(org.eclipse.core.runtime_3.2.0.v20060603.jar.so)
at com.redhat.eclipse.cdt.autotools.ui.LibHover.buildDocPath(com.redhat.eclipse.cdt.autotools_0.0.2.jar.so)
at com.redhat.eclipse.cdt.autotools.ui.LibHover.initialize(com.redhat.eclipse.cdt.autotools_0.0.2.jar.so)
at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor$1.run(CHelpProviderDescriptor.java:106)
at org.eclipse.core.runtime.SafeRunner.run(org.eclipse.equinox.common_3.2.0.v20060603.jar.so)
at org.eclipse.core.runtime.Platform.run(org.eclipse.core.runtime_3.2.0.v20060603.jar.so)
at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpProvider(CHelpProviderDescriptor.java:111)
at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpProvider(CHelpProviderDescriptor.java:126)
at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpBookDescriptors(CHelpProviderDescriptor.java:132)
at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getCHelpBookDescriptors(CHelpProviderDescriptor.java:152)
at org.eclipse.cdt.internal.ui.text.CHelpProviderDescriptor.getEnabledMatchedCHelpBooks(CHelpProviderDescriptor.java:156)
at org.eclipse.cdt.internal.ui.text.CHelpSettings.getFunctionInfo(CHelpSettings.java:117)
at org.eclipse.cdt.internal.ui.CHelpProviderManager.getFunctionInfo(org.eclipse.cdt.ui_3.1.0.200607240538.jar.so)
at org.eclipse.cdt.internal.ui.text.c.hover.CDocHover.getHoverInfo(CDocHover.java:71)
at org.eclipse.cdt.internal.ui.text.c.hover.BestMatchHover.getHoverInfo(BestMatchHover.java:100)
at org.eclipse.cdt.internal.ui.text.c.hover.CEditorTextHoverProxy.getHoverInfo(CEditorTextHoverProxy.java:64)
at org.eclipse.jface.text.TextViewerHoverManager$4.run(org.eclipse.jface.text_3.2.0.v20060605-1400.jar.so)
Any idea what's going on here?
Thanks,
Andrew
17 years, 10 months
where is libjawt.so?
by Anthony Green
Tom, Jakub,
I'm trying to rebuild jogl against the latest devel bits and I don't
see where libjawt.so moved to. I only see libgcjawt.so. Pointers?
Thanks!
AG
17 years, 10 months