Re: [kaffe] java.lang.IllegalAccessError
On Fri, 24 Oct 2003 20:14:38 +0200
Guilhem Lavaux [EMAIL PROTECTED] wrote:
Hi Guilhem, hi Ito,
The attached programs cause java.lang.IllegalAccessError,
which partly seemes to have something to do with KJC,
but class files compiled with Sun's javac also cause the
error.
Apparently KJC choses to protect the inner class (as usual). I've not
really seen a specific restriction about access modifiers concerning
inner classes in doc but the JDK's compiler put your sample class in
public access (even though you explicitly specified it protected). The
best guess I can make is to ignore the access modifier for inner classes
in KJC. I'll prepare this for tomorrow.
I don't think that this would be the correct fix (altering
the access modifiers during compilation doesn't look right
to me). For a discussion of a similar problem have a look
at the thread starting at this mail:
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=Pine.LNX.4.10.10010111327040.12800-10%40green.usr.onet
I think the real problem is kaffe's runtime access checking,
which is why I'm about to check in the following patch:
Index: kaffe/kaffevm/access.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/access.c,v
retrieving revision 1.3
diff -u -r1.3 access.c
--- kaffe/kaffevm/access.c 22 Sep 2003 15:31:24 - 1.3
+++ kaffe/kaffevm/access.c 25 Oct 2003 08:16:09 -
@@ -116,7 +118,29 @@
{
class_acc = 1;
}
+ else if( (target-this_inner_index = 0)
+(target-accflags ACC_PROTECTED) )
+ {
+ /* check whether target is non private innerclass of superclass */
+ innerClass *ic = target-inner_classes[target-this_inner_index];
+
+ if( ic-outer_class )
+ {
+ Hjava_lang_Class *outer;
+ errorInfo einfo;
+ outer = getClass(ic-outer_class, target, einfo);
+ if( outer != NULL )
+ {
+ class_acc = instanceof(outer, context);
+ }
+ else
+ {
+ discardErrorInfo(einfo);
+ }
+ }
+ }
+
Kaffe's runtime access checking denies access to
protected inherited inner classes, which is why
we get the IllegalAccessException.
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Hi
Hi every body, I'm a new user in Kaffe, I try to use kaffe plugin for mozilla, I'va got kaffe-1.1.2 and compile it, it works good, but i can not compile its plugin, I've used kaffeOJIPlugin,but when i compile it, it has some many error, would u please guide me ... :) @};- TNX Amir __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] CVS kaffe (hkraemer): miscellaneous small fixes
PatchSet 4123
Date: 2003/10/25 12:52:41
Author: hkraemer
Branch: HEAD
Tag: (none)
Log:
miscellaneous small fixes
Members:
ChangeLog:1.1715-1.1716
config/arm/common.h:1.7-1.8
config/arm/trampolines.c:1.5-1.6
config/arm/linux/jit-md.h:1.6-1.7
config/arm/linux/md.h:1.5-1.6
config/sparc/jit.h:1.7-1.8
include/jni.h:1.22-1.23
include/jni_cpp.h:1.6-1.7
kaffe/kaffevm/access.c:1.3-1.4
libraries/clib/net/Makefile.am:1.13-1.14
libraries/clib/net/Makefile.in:1.86-1.87
libraries/javalib/java/awt/MouseEvt.java:1.7-1.8
libraries/javalib/java/net/URLClassLoader.java:1.12-1.13
Index: kaffe/ChangeLog
diff -u kaffe/ChangeLog:1.1715 kaffe/ChangeLog:1.1716
--- kaffe/ChangeLog:1.1715 Fri Oct 24 16:42:09 2003
+++ kaffe/ChangeLog Sat Oct 25 12:52:41 2003
@@ -1,3 +1,44 @@
+2003-10-25 Helmer Kraemer [EMAIL PROTECTED]
+
+ * config/arm/linux/jit-md.h:
+ removed now unnecessary signal stuff, corrected the definition of
+ the FIRSTFRAME macro
+
+ * config/arm/linux/md.h:
+ include necessary signal related headers, corrected the definition
+ of the SIGNAL_ARGS macro
+
+ * config/arm/trampolines.c:
+ (arm_do_fixup_trampoline) create a stack frame for the trampoline
+
+ * config/arm/common.h:
+ (sysdepCallMethod) fixed passing of 64bit parameters, made asm
+ statements volatile so gcc doesn't optimize them away
+
+ * config/sparc/jit.h:
+ (CALL_KAFFE_EXCEPTION) removed wrong quote
+
+ * kaffe/kaffevm/access.c:
+ (checkAccess) properly grant access to inherited inner classes
+ that are protected
+
+ * include/jni.h, include/jni_cpp.h:
+ added missing c++ functions for the VM Invocation Interface
+
+ * libraries/javalib/java/awt/MouseEvt.java:
+ (computeMouseTarget) properly translate the mouse position
+ when the mouse is inside of a container
+
+ Reported by: Ross Martin [EMAIL PROTECTED]
+
+ * libraries/javalib/java/net/URLClassLoader.java:
+ (getJar) immediately return if the url denotes a local file
+ that doesn't exist
+
+ * libraries/clib/net/Makefile.am, libraries/clib/net/Makefile.in:
+ (libnet_la_LDADD) make sure that symbols starting with gnu are
+ exported
+
2003-10-24 Dalibor Topic [EMAIL PROTECTED]
* libraries/javalib/java/util/zip/ZipInputStream.java:
Index: kaffe/config/arm/common.h
diff -u kaffe/config/arm/common.h:1.7 kaffe/config/arm/common.h:1.8
--- kaffe/config/arm/common.h:1.7 Tue Sep 30 19:50:54 2003
+++ kaffe/config/arm/common.h Sat Oct 25 12:52:42 2003
@@ -36,76 +36,53 @@
register int r2 asm(r2);
register int r3 asm(r3);
register double f0 asm(f0);
+
default:
{
int *args = extraargs;
int argidx = 4;
- if (call-callsize[3] == 2) {
- *args++ = (call-args[argidx].j) 32;
- }
for(; argidx call-nrargs; ++argidx) {
- if (call-callsize[argidx]) {
- *args++ = call-args[argidx].i;
- if (call-callsize[argidx] == 2)
- *args++ = (call-args[argidx].j) 32;
- }
+*args++ = call-args[argidx].i;
}
}
case 4:
-if (call-callsize[3]) {
- r3 = call-args[3].i;
- if (call-callsize[3] == 2)
-*extraargs = (call-args[3].j) 32;
-}
+r3 = call-args[3].i;
case 3:
-if (call-callsize[2]) {
- r2 = call-args[2].i;
- if (call-callsize[2] == 2)
-r3 = (call-args[2].j) 32;
-}
+r2 = call-args[2].i;
case 2:
-if (call-callsize[1]) {
- r1 = call-args[1].i;
- if (call-callsize[1] == 2)
-r2 = (call-args[1].j) 32;
-}
+r1 = call-args[1].i;
case 1:
-if (call-callsize[0]) {
- r0 = call-args[0].i;
- if (call-callsize[0] == 2)
-r1 = (call-args[0].j) 32;
-}
+r0 = call-args[0].i;
case 0:
-asm (mov lr, pc\n
-mov pc, %3\n
-: =r (r0), =r (r1), =f (f0)
- : r (call-function),
- 0 (r0), 1 (r1), r (r2), r (r3)
- : ip, rfp, sl, fp, lr
- );
-switch(call-rettype)
+asm volatile (mov lr, pc\n
+mov pc, %3\n
+ : =r (r0), =r (r1), =f (f0)
+ : r (call-function),
+0 (r0), 1 (r1), r (r2), r (r3)
+ : ip, rfp, sl, fp, lr);
+switch (call-rettype)
{
+case 'V':
+ break;
+
case 'D':
-asm(stfd %1,%0 : =m (call-ret-d) : f (f0));
- break;
+ asm volatile (stfd %1,%0 : =m (call-ret-d) : f (f0));
+ break;
+
case 'F':
- asm(stfs %1,%0 : =m (call-ret-f) : f (f0));
- break;
-/*
- * XXX doesn't seem to be necessary to special case 'L',
- * since its just another 32bit int, right !??!??
-case 'L':
- call-ret-l = r0;
- break;
- */
+ asm volatile (stfs
Re: [kaffe] java.lang.IllegalAccessError
Helmer Krämer wrote: On Fri, 24 Oct 2003 20:14:38 +0200 Guilhem Lavaux [EMAIL PROTECTED] wrote: Hi Guilhem, hi Ito, The attached programs cause java.lang.IllegalAccessError, which partly seemes to have something to do with KJC, but class files compiled with Sun's javac also cause the error. Apparently KJC choses to protect the inner class (as usual). I've not really seen a specific restriction about access modifiers concerning inner classes in doc but the JDK's compiler put your sample class in public access (even though you explicitly specified it protected). The best guess I can make is to ignore the access modifier for inner classes in KJC. I'll prepare this for tomorrow. I don't think that this would be the correct fix (altering the access modifiers during compilation doesn't look right to me). For a discussion of a similar problem have a look at the thread starting at this mail: http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=Pine.LNX.4.10.10010111327040.12800-10%40green.usr.onet I think the real problem is kaffe's runtime access checking, which is why I'm about to check in the following patch: Yes, but this doesn't solve the problem concerning JDK. If you disassemble the code generated from the classes provided by Ito you may notice that the inner class doesn't have any protection although it is protected. But I've made another test with private and apparently it changes something also concerning the modifier, so the problem should be more complicated. Cheers, Guilhem. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] java.lang.IllegalAccessError
On Sat, 25 Oct 2003 17:07:52 +0200 Guilhem Lavaux [EMAIL PROTECTED] wrote: Helmer Krämer wrote: On Fri, 24 Oct 2003 20:14:38 +0200 Guilhem Lavaux [EMAIL PROTECTED] wrote: Hi Guilhem, hi Ito, The attached programs cause java.lang.IllegalAccessError, which partly seemes to have something to do with KJC, but class files compiled with Sun's javac also cause the error. Apparently KJC choses to protect the inner class (as usual). I've not really seen a specific restriction about access modifiers concerning inner classes in doc but the JDK's compiler put your sample class in public access (even though you explicitly specified it protected). The best guess I can make is to ignore the access modifier for inner classes in KJC. I'll prepare this for tomorrow. I don't think that this would be the correct fix (altering the access modifiers during compilation doesn't look right to me). For a discussion of a similar problem have a look at the thread starting at this mail: http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=Pine.LNX.4.10.10010111327040.12800-10%40green.usr.onet I think the real problem is kaffe's runtime access checking, which is why I'm about to check in the following patch: Yes, but this doesn't solve the problem concerning JDK. If you disassemble the code generated from the classes provided by Ito you may notice that the inner class doesn't have any protection although it is protected. But I've made another test with private and apparently it changes something also concerning the modifier, so the problem should be more complicated. The problem is that Base$Base1.class contains two different sets of access modifiers that are applicable to Base.Base1 . One set is stored in the 2 bytes following the constant pool, the other one can be extracted from the InnerClasses attribute of the constant pool. As far as inner classes are concerned, these two sets don't seem to be identical. The one that is stored outside of the constant pool doesn't seem to resemble the set of modifiers given in the corresponding source file, whereas the one that is stored in the InnerClasses attribute does. The difference between jikes, javac and kjc is what they do with the set stored outside of the constant pool. Javac and jikes put the ACC_PUBLIC bit in this set, whereas kjc leaves it alone. As you've said, this set even looks different when the inner class is declared private. However, the interesting question is, which set is to be choosen when verifying accesses between classes at runtime. Kaffe at least drops the one stored outside the constant pool and only works with the one extracted from the InnerClasses attribute, which is why kaffe works with my patch applied. So, the question is whether the contents of the set stored outside of the constant pool are specified for inner classes or whether they're unspecified and setting ACC_PUBLIC in it is just a work around for some vm, verifier, whatever, that doesn't extract the access modifiers from the constant pool. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] java.lang.IllegalAccessError
This is an aspect of a known security misfeature of inner classes: some access controls which are enforced by the compiler cannot be enforced by the VM with the same granularity, because the VM doesn't really grok the inner/outer class hierarchy. E.g from http://www.lsd-pl.net/documents/javasecurity-1.0.0.pdf: blockquoteIn the case where system classes use inner classes, these inner classes can be accessed from anycode in the same package. This is due to the fact that Java bytecode has no concept of inner classes,so they are translated by the compiler into ordinary classes. Besides, inner classes are allowed toaccess private fields of the outer classes. This is caused by the fact that they are always translatedinto separate classes. Therefore, in order to let the inner class access the fields of the correspondingouter class, the compiler silently changes these fields from private to package scope. /blockquote Chris On Saturday 25 October 2003 17:07, Guilhem Lavaux wrote: Helmer Krämer wrote: On Fri, 24 Oct 2003 20:14:38 +0200 Guilhem Lavaux [EMAIL PROTECTED] wrote: Hi Guilhem, hi Ito, The attached programs cause java.lang.IllegalAccessError, which partly seemes to have something to do with KJC, but class files compiled with Sun's javac also cause the error. Apparently KJC choses to protect the inner class (as usual). I've not really seen a specific restriction about access modifiers concerning inner classes in doc but the JDK's compiler put your sample class in public access (even though you explicitly specified it protected). The best guess I can make is to ignore the access modifier for inner classes in KJC. I'll prepare this for tomorrow. I don't think that this would be the correct fix (altering the access modifiers during compilation doesn't look right to me). For a discussion of a similar problem have a look at the thread starting at this mail: http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=Pine.LNX.4.10.1001 0111327040.12800-10%40green.usr.onet I think the real problem is kaffe's runtime access checking, which is why I'm about to check in the following patch: Yes, but this doesn't solve the problem concerning JDK. If you disassemble the code generated from the classes provided by Ito you may notice that the inner class doesn't have any protection although it is protected. But I've made another test with private and apparently it changes something also concerning the modifier, so the problem should be more complicated. Cheers, Guilhem. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe -- Chris Gray/k/ Embedded Java Solutions Embedded Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] jboss vs. java.util.zip
Hi all, I tried to find out why it was necessary to modify java.util.zip in order to get jboss to run, and the results were a bit surprising. The exception that is thrown when the patch is not applied is this one: java.io.IOException: Bogus signature: 0x6d783f3c at java.util.zip.ZipInputStream.getNextEntry (ZipInputStream.java:52) at org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterator.getNextEntry (ClassLoaderUtils.java:533) at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap (ClassLoaderUtils.java:245) at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap (ClassLoaderUtils.java:179) at org.jboss.mx.loading.UnifiedLoaderRepository3.updatePackageMap (UnifiedLoaderRepository3.java:651) at org.jboss.mx.loading.UnifiedLoaderRepository3.addUnifiedClassLoader (UnifiedLoaderRepository3.java:633) at org.jboss.mx.loading.UnifiedLoaderRepository3.addClassLoader (UnifiedLoaderRepository3.java:572) at org.jboss.mx.loading.UnifiedLoaderRepository3.registerClassLoader (UnifiedLoaderRepository3.java:796) at org.jboss.mx.loading.UnifiedLoaderRepository3.newClassLoader (UnifiedLoaderRepository3.java:134) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.deployment.DeploymentInfo.createClassLoaders (DeploymentInfo.java:223) at org.jboss.deployment.MainDeployer.init (MainDeployer.java:688) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:629) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:589) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy5.deploy (source file unknown) at org.jboss.system.server.ServerImpl.doStart (ServerImpl.java:384) at org.jboss.system.server.ServerImpl.start (ServerImpl.java:291) at org.jboss.Main.boot (Main.java:150) at org.jboss.Main$1.run (Main.java:388) at java.lang.Thread.run (Thread.java:310) Inspecting the bogus signature a little bit more, I found out that 0x6d783f3c is ?xm, which looks a lot like the first four bytes of an xml file. In order to debug this a little bit more, I inserted a few debugging messages: [EMAIL PROTECTED] is for /cvsstuff/tmp/jboss-3.2.2RC4/server/default/tmp/deploy/tmp1067099841870jboss-service.xml java.lang.Throwable at java.lang.Thread.dumpStack (Thread.java:157) at java.io.FileInputStream.init (FileInputStream.java:111) at org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterator.init (ClassLoaderUtils.java:516) at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap (ClassLoaderUtils.java:177) at org.jboss.mx.loading.UnifiedLoaderRepository3.updatePackageMap (UnifiedLoaderRepository3.java:651) at org.jboss.mx.loading.UnifiedLoaderRepository3.addUnifiedClassLoader (UnifiedLoaderRepository3.java:633) at org.jboss.mx.loading.UnifiedLoaderRepository3.addClassLoader (UnifiedLoaderRepository3.java:572) at org.jboss.mx.loading.UnifiedLoaderRepository3.registerClassLoader (UnifiedLoaderRepository3.java:796) at org.jboss.mx.loading.UnifiedLoaderRepository3.newClassLoader (UnifiedLoaderRepository3.java:134) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.deployment.DeploymentInfo.createClassLoaders (DeploymentInfo.java:223) at org.jboss.deployment.MainDeployer.init (MainDeployer.java:688) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:629) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:589) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy5.deploy (source file unknown) at org.jboss.system.server.ServerImpl.doStart (ServerImpl.java:384) at org.jboss.system.server.ServerImpl.start (ServerImpl.java:291) at org.jboss.Main.boot (Main.java:150) at org.jboss.Main$1.run (Main.java:388) at java.lang.Thread.run (Thread.java:310)
[kaffe] OOM and jit3
Hi, I'm trying to get Kaffe to get as much of Jakarta Gump to compile as I can. http://kaffe.org/~jim/gump/log/ I encountered this while trying to build xml-xalan2: kaffe-bin: ../../../../kaffe/kaffe/kaffevm/jit3/seq.c:60: nextSeq: Assertion `sc != ((void *)0)' failed. Looking at the code, it seems gc_malloc() failed, and the JIT just asserts. Shouldn't it be posting an out of memory exception instead? Or is there a reason we can't? I was able to get past the issue with -Xmx256M. Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Hi
Amir Hossein payberah wrote: Hi every body, I'm a new user in Kaffe, I try to use kaffe plugin for mozilla, I'va got kaffe-1.1.2 and compile it, it works good, but i can not compile its plugin, I've used kaffeOJIPlugin,but when i compile it, it has some many error, Hi Amir, the OJI plugin doesn't work with kaffe 1.1.2 yet, Aleksandr Abakin is working on it, but has some problems with a threading issue. See his post here: http://www.kaffe.org/pipermail/kaffe/2003-October/044131.html cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] CVS kaffe (dalibor): Upgraded to automake 1.7.8
PatchSet 4125 Date: 2003/10/25 20:00:11 Author: dalibor Branch: HEAD Tag: (none) Log: Upgraded to automake 1.7.8 Members: ChangeLog:1.1717-1.1718 Makefile.in:INITIAL-1.115 aclocal.m4:1.69-1.70 depcomp:1.6-1.7 missing:1.7-1.8 FAQ/FAQ.automake:1.19-1.20 config/Makefile.in:INITIAL-1.90 developers/autogen.sh:1.16-1.17 include/Makefile.in:1.123-1.124 kaffe/Makefile.in:1.81-1.82 kaffe/jvmpi/Makefile.in:1.6-1.7 kaffe/kaffe/Makefile.in:1.95-1.96 kaffe/kaffeh/Makefile.in:1.82-1.83 kaffe/kaffevm/Makefile.in:INITIAL-1.115 kaffe/kaffevm/gcj/Makefile.in:INITIAL-1.64 kaffe/kaffevm/intrp/Makefile.in:1.71-1.72 kaffe/kaffevm/jit/Makefile.in:1.77-1.78 kaffe/kaffevm/jit3/Makefile.in:1.47-1.48 kaffe/kaffevm/systems/Makefile.in:1.73-1.74 kaffe/kaffevm/systems/beos-native/Makefile.in:1.64-1.65 kaffe/kaffevm/systems/oskit-pthreads/Makefile.in:1.70-1.71 kaffe/kaffevm/systems/unix-jthreads/Makefile.in:1.73-1.74 kaffe/kaffevm/systems/unix-pthreads/Makefile.in:1.43-1.44 kaffe/man/Makefile.in:1.71-1.72 kaffe/scripts/Makefile.in:1.104-1.105 kaffe/scripts/bat/Makefile.in:1.64-1.65 kaffe/scripts/compat/Makefile.in:1.87-1.88 kaffe/xprof/Makefile.in:1.39-1.40 libltdl/Makefile.in:1.33-1.34 libltdl/aclocal.m4:1.37-1.38 libraries/Makefile.in:1.68-1.69 libraries/clib/Makefile.in:INITIAL-1.74 libraries/clib/awt/Makefile.in:1.81-1.82 libraries/clib/awt/X/Makefile.in:1.71-1.72 libraries/clib/awt/qt/Makefile.in:1.26-1.27 libraries/clib/io/Makefile.in:1.74-1.75 libraries/clib/management/Makefile.in:1.83-1.84 libraries/clib/math/Makefile.in:1.79-1.80 libraries/clib/native/Makefile.in:1.106-1.107 libraries/clib/net/Makefile.in:1.87-1.88 libraries/clib/security/Makefile.in:1.47-1.48 libraries/clib/zip/Makefile.in:1.81-1.82 libraries/extensions/Makefile.in:1.59-1.60 libraries/extensions/comm/Makefile.in:1.54-1.55 libraries/extensions/comm/javalib/Makefile.in:1.54-1.55 libraries/extensions/microsoft/Makefile.in:1.46-1.47 libraries/extensions/microsoft/clib/Makefile.in:1.49-1.50 libraries/extensions/microsoft/javalib/Makefile.in:1.47-1.48 libraries/extensions/pjava/Makefile.in:1.54-1.55 libraries/extensions/pjava/javalib/Makefile.in:1.54-1.55 libraries/extensions/servlet/Makefile.in:1.54-1.55 libraries/extensions/servlet/javalib/Makefile.in:1.54-1.55 libraries/extensions/sound/Makefile.in:1.22-1.23 libraries/extensions/sound/alsa/Makefile.in:1.24-1.25 libraries/extensions/sound/common/Makefile.in:1.24-1.25 libraries/extensions/sound/esd/Makefile.in:1.24-1.25 libraries/javalib/Makefile.am:1.140-1.141 libraries/javalib/Makefile.in:1.188-1.189 replace/Makefile.in:1.18-1.19 test/Makefile.in:1.74-1.75 test/internal/Makefile.in:1.28-1.29 test/regression/Makefile.in:1.137-1.138 test/regression/compile_time/Makefile.in:1.2-1.3 test/regression/run_time/Makefile.in:INITIAL-1.3 Index: kaffe/ChangeLog diff -u kaffe/ChangeLog:1.1717 kaffe/ChangeLog:1.1718 --- kaffe/ChangeLog:1.1717 Sat Oct 25 18:30:20 2003 +++ kaffe/ChangeLog Sat Oct 25 20:00:11 2003 @@ -1,5 +1,74 @@ 2003-10-25 Dalibor Topic [EMAIL PROTECTED] + * FAQ/FAQ.automake: Recommend autmake 1.7.8. + + * developers/autogen.sh: Upgraded to automake 1.7.8. + +* Makefile.in, +aclocal.m4, +depcomp, +missing, +config/Makefile.in, +include/Makefile.in, +kaffe/Makefile.in, +kaffe/jvmpi/Makefile.in, +kaffe/kaffe/Makefile.in, +kaffe/kaffeh/Makefile.in, +kaffe/kaffevm/Makefile.in, +kaffe/kaffevm/gcj/Makefile.in, +kaffe/kaffevm/intrp/Makefile.in, +kaffe/kaffevm/jit/Makefile.in, +kaffe/kaffevm/jit3/Makefile.in, +kaffe/kaffevm/systems/Makefile.in, +kaffe/kaffevm/systems/beos-native/Makefile.in, +kaffe/kaffevm/systems/oskit-pthreads/Makefile.in, +kaffe/kaffevm/systems/unix-jthreads/Makefile.in, +kaffe/kaffevm/systems/unix-pthreads/Makefile.in, +kaffe/man/Makefile.in, +kaffe/scripts/Makefile.in, +kaffe/scripts/bat/Makefile.in, +kaffe/scripts/compat/Makefile.in, +kaffe/xprof/Makefile.in, +libltdl/Makefile.in, +libltdl/aclocal.m4, +libraries/Makefile.in, +libraries/clib/Makefile.in, +libraries/clib/awt/Makefile.in, +libraries/clib/awt/X/Makefile.in, +libraries/clib/awt/qt/Makefile.in, +libraries/clib/io/Makefile.in, +libraries/clib/management/Makefile.in, +
