Hi,
I have put new linux-mips disk image on http://www.kaffe.org/~inaba/mips
(Thanks Jim to maintain this server!). As usual root and kaffe accounts
have password 'dalibor'.
You may find two directories in kaffe/src, one is compiled with gcc-3.4
and the other is compiled with gcc-4.3. Both
Update, summary: 28 of 150 tests failed.
(You have to interpret this message as 122 of 150 tests passed.
We are salespersons for shoes who happened to arrive to an island
in which no one wear shoes.)
OK, detailed info (maybe part 1)
There were several guys (including Kevin D. Kissell,
Even we have long silence on the list, someone may continue some effort
to improve kaffe...
For this summer, my SOC (summer of code) was to tackle arm jit3 code.
# Oh, this topic is same as the last summer :-)
Of course, the released version has a workable jit3 code for this arch,
if you think
Hi Mahesh,
Im a newbie, I have compiled kaffe 1.1.9 for arm on fedora8. When I
try to compile Hello world program using kaffe I get a bus error
I noticed, fedora team made good wiki for running it on QEMU
http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu
but have not time
Hi,
I've put build images for NetBSD and linux arm on the kaffe server.
You can get images in
http://www.kaffe.org/~inaba
and 'README' file in this directory tells you what files are needed
to run.
The executable images 'gxemul' and 'qemu-system-arm' is compiled on
Fedora core 5 for
Hi,
Yesterday, I've committed 'partial port' of kaffe to arm/netbsd/jit3.
This port is different from arm/linux port, because NetBSD port does
not use (1) any floating point instructions. The current linux port
uses slightly old FPA instructions (with hardware support or software
emulation
Hi Jim,
I think this is the first commit in 5 months since Dalibor did the last
release. I notice that the CVS email script seems to be broken -- and I
still need to fix Bugzilla.
Yeah, I wait for the CVS mail received, and reached to the same conclusion.
If you can fix it, it is so helpful for
I tried with libtool 1.5.26 as well as 1.5.18. But getting the same
problem.
...
checking for ltdl.h... yes
checking for library containing lt_dlcaller_register... no
configure: error: Can't find the libltdl library.
Of course, if you don't put your old (v1.5 series) libltdl in your library
Hi Debashish,
I have downloaded the library libtool from
http://ftp.gnu.org/gnu/libtool/libtool-2.2.4.tar.gz
I was encountered same problem recently for newly installed environment.
The checking for libtool invokes some deprecated functions, and you
have to install some 1.5.x (I did with 1.5.26)
Hi Ito-san,
Strangely enough, this test passed when I did it on FreeBSD 6.2-RELEASE.
Does this problem have something to do with zziplib?
I don't think so. I just installed a new file server with FB-6.3, and
the regression (against 08/02/07 snap) tells me
All 149 tests behaved as expected (2
Since we eliminated all imported packages, (if I understand correctly)
the macro 'KAFFE_CFLAGS' may not be needed.
Am I right?
Kiyo
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Wow, you did it by yourself...
Dalibor Topic wrote:
Dalibor Topic wrote:
Dalibor Topic wrote:
My plan would be to look at making the interpreter pass on arm-oabi
and arm-eabi without failures, and then
to move on to the jits.
Yes, in general tackling interpreter version first is a good
Hi Galvez,
I am trying to cross compile my kaffe using ARM-Linux GNU EABI
I know your problem does not come from this reason, but as FAQ.arm says,
EABI is not supported right now.
Kiyo
___
kaffe mailing list
kaffe@kaffe.org
Hi Dalibor,
For native builds in qemu, you can grab the armel debian image from
http://www.kaffe.org/~robilad/qemu/ (user root pass debian, user test
pass test), build classpath 0.96.1 using a prebuilt glibj.zip (i.e.
http://www.kaffe.org/~robilad/glibj.zip) as the memory QEmu can simulate
for
By the way, the reason why your build stops is
The config completed successfully using the command line:
KAFFEH=/usr/local/kaffe/bin/kaffe CC=3Darm-angstrom-linux-gnueabi-gcc ...
You specify 'kaffe' rather than some 'javah' program to the variable
KAFFEH.
Kiyo
Dalibor Topic wrote:
Kiyo Inaba wrote:
As far as NetBSD is concerned, the emulator 'gxemul' supports NetBSD
to be booted (with which I tested for kaffe-1.1.7) but unfortunately
the 'gdb' program in this environment causes illegal instruction. I
am now considering to purchase real board which
Hi Robert,
I just tried to cross-compile kaffe for ARM (I read the FAQ :) ). The
It's good to hear from someone that FAQ.cross-compiling is useful ;-)
target (and toolchain) is GNU EABI which is not officially supported in
kaffe. So perhaps my compile error is just because of that - I get this:
Hi,
I noticed if I install 'libgc.so' in /usr/local/lib, the wrapper script
'kaffe-bin' always trys to load this library (even for 'kaffe-gc') and
if I did not set LD_LIBRARY_PATH to include /usr/local/lib, 'kaffe-bin'
generates error message saying
kaffe/kaffe/.libs/lt-kaffe-bin: error
Dalibor Topic wrote:
Kiyo Inaba wrote:
I found it can be extended until major classpath resync on Jan of
2007 if I revert the mod for 'kaffe/kaffevm/baseClasses.c'. The change
made in 'baseClasses.c' (v 1.76) is reorder the invocation of
initialization (initializeSecurity and initThreads). I
I wrote:
Dalibor Topic wrote:
My current results with boehm-gc are a bit across the map (i386-linux,
boehm-gc 6.8, different compilers, CVS head).
This report is very interesting for me.
I tested boehm with three systems.
1) i386, gcc version 3.2 20020903, Red Hat Linux 8.0 3.2-7
2) i386, gcc
Hi,
After submitting several archived tests, I found snap 060803
(whose ChangeLog head is 2006-07-27 Guilhem Lavaux [EMAIL PROTECTED])
works fine with Boehm GC on i386/linux. I will try to use this to test
whether arm version of Boehm GC works fine.
I found it can be extended until major
Hi Zigurd,
We tried using Boehm GC, but encountered an issue which is now bug #113.
Any experiences/pointers getting Boehm GC up on ARM Linux would also be
very useful.
I usually don't test ports with Boehm GC, and takes time to notice this
bug. I am afraid Boehm GC for arm has never tested...
Dalibor wrote:
This is the great news for me! After I changed to use ecj for all
platforms, the regression testing itself took more than 51 hours
on m68k (Mac-IIci, netbsd) :- For the next weekly regression test,
I can see whether things becomes better or not.
I hope they will become
Dalibor wrote:
It becomes 10.5 hours, so your improvement really works :-)
Great! Is that in the range of the time required for testing using jikes?
It usually takes roughly 10.5 hours. Of course jikes case invokes jikes
for every test case, and may have slight improvement if I do same
Dalibor wrote:
The auto detection itself is welcome, but still I want to have
explicit way to specify which compiler is my preference. Since
I still use jikes for some other staff, but when making regression
test of kaffe I need to use ecj (jikes does not like classpath-0.96.1).
Yeah. Just
Hi Dalibor and others,
Dalibor wrote: (slightly reformat)
I've changed the compilation of the regression steps to compile all
tests in a single step, which should speed up the regression tests
in particular for users using ecj / javac on a JVM, as that eliminates
around 150 JVM invocations.
This
Hi,
Even right now, we have one existence of use_glibj_zip in 'configure'
or 'configure.ac'. In 'configure.ac', it is at line 2247.
If I understand correctly, when we removed with_glibj_zip option for
'configure' this variable does have no meaning. Could someone (maybe
Dalibor?) investigate
Hi Gilles,
checking for ESD - version = 0.2.1... no
*** The esd-config script installed by ESD could not be found
*** If ESD was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the ESD_CONFIG environment variable to the
*** full path to esd-config.
Useable version of ESD not
Hi Dario,
I can bypass with --disable-vmdebug but I really need to -vmdebug to figure
out why jni is failing at runtime.
Not a real fix, but when you cross compiling kaffe, kaffeh in the build
tree is not used anyway.
Kiyo
___
kaffe mailing list
Hi Abderrazek,
What other changes must be done?
Please see FAQ/FAQ.cross-compiling.
Kiyo
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Hi,
now that 1.1.8 is out, I wondered what people are planning on to do for
1.1.9. I've got a couple of things on my list, please reply if there is
something else you're working on, or if there is something you're
interested in tackling.
I have several things on my list.
But, since 1.1.9 is to
Hi,
After having some sleep, and after business hours, I restart to search
how darwin code are released, and whether they can be compatible with
kaffe's current license.
P.S. By the way, the 'project home' for this project tells me this
project is covered by 'New BSD License', but the
Hi KK,
I am trying to port Kaffe to MINIX 3. I am new to Kaffe. So I have a
query before I start to port. I will be very beneficial for me to have
your guidance and support. I request you to please give me any input
that you feel will help me.
Which version of Kaffe is best to port initially? (I
Hi,
I am now trying to speedup configuration/make speed on slower machine,
and try to use preinstalled classpath. If I specify '--with-system-classpath'
to the configure script, the script still tries to invoke configure in
its subdir for classpath. I think this recursive configuration is not
Fully off topic.
Please tackle the bug:
http://www.kaffe.org/cgi-bin/bugzilla/show_bug.cgi?id=100
Congratulation, Kaz!
We finally reach next level of bug reports :-)
Kiyo
___
kaffe mailing list
kaffe@kaffe.org
Dalibor wrote:
Kiyo Inaba wrote:
Finished. The list is attached.
'Double' related 8 tests are known not to work. The fix may not take
a lot of time, but I will do that after the release.
Thank you very much for doing the tests, Kiyo. Could you add the results
to FAQ/FAQ.platform-status?
Oh, I
Hi Ashok,
I am getting this following bug while executing 'make check'.
I am using ppc based embedded device.
I have executed the following configuration:
./configure --with-qtdir=/home/amit/qt-2.3.2
--with-qt-headers=/home/amit/qt-2.3.2/include
--with-qt-binaries=/home/amit/qt-2.3.2/bin
Still it does not work, but I finally found where the bug is...
According to the assembler listing of the method 'loadClass' (which
is attached at the very end of this mail), the argument one (which is
passed by register r1) is once stored in register r6, and has a copy
in [r11, #-72]. But at
I wrote:
Recent version of kaffe got 'UnsatisfiedLinkError' on arm/linux/jit.
I guess, this is because of static-vm, static-lib fix.
It's my mistake. When I reverted my mod for 'jit.h', it works.
Kiyo
___
kaffe mailing list
kaffe@kaffe.org
Hi Arun,
I tried to search the mailing list for similar problem and got some
questions which seemed alike. But there is no clear solution for this except
an indication it may be related to threads.
Thanks for the bug report. I can not find any info saying how to fix
this right now. And I don't
Ronald,
Ronald Sloot wrote:
We're trying to add VFP and EABI support to the Kaffe jit engine for
ARM. If anyone else is doing that already, let us know so that we can
share our findings.
It is very welcome to have VFP or EABI support for the Kaffe. For the
last several month, I started to check
Ronald,
Ronald Sloot wrote:
At the moment we are trying to first pass all the jitBasic test cases.
We updated the jit-arm.def to emit VFP instructions instead of VPA and
made some other temporary changes related to EABI. We've not passed all
jitBasic test cases yet. Will keep you posted. Note: we
Dalibor Topic wrote:
Dalibor Topic wrote:
Kiyo Inaba wrote:
Dalibor, could you please add some code to check the version of libz?
I could check if ZLIB_VERNUM = 0x1230, and abort configure accordingly,
to make sure kaffe is built with zlib 1.2.3 or higher.
fix checked in now. Thank you very
trip...), I noticed the same snapshot is OK for FC5. So, I think there
should be some OS depend error was introduced. The latest weekly
snap works fine is 070607.
Looks like, I did not install libzip on these machines.
Isn't it better to check the existence of libzip?
Kiyo
Kiyo Inaba wrote:
Dalibor Topic wrote:
Yes, now that we depend on it, we should make sure it's there in
configure. Thanks, I'll check in a patch.
Oops, I misunderstand the name of the library. I have 'libz' installed.
One possibility is the (os) installed version is 1.1.4. Is this version
to old
For the weekly regression test I did for i386/m68k, CVS head fails the
regression test. I checked this with i386/linux (kernel version 2.4.18-14)
and m68k/linux (kernel version 2.2.20).
The 'HelloWorldApp.fail' says
Couldn't find or load essential class `java/io/Serializable'
Hi, [EMAIL PROTECTED]
My question is how to get a kaffe full static binary in a
crosscompilation to MIPS platform
I tried setting --wiht.staticlib --wiht.staticbin and --wiht.staticvm in
the configure and it does not work 100%, it requires the libraries
generated in kaffe/jre/lib/mips.
Currently
Dalibor and others,
Dalibor wrote:
D) Merge in tbfg's m68k patch. Kiyo, could you take a look at it?
http://www.kaffe.org/pipermail/kaffe/2007-June/104949.html
Yes, I've spent some time to investigate this proposal.
In general, the patch posted tries to comment out some instructions
which are
Hi Dalibor,
It should be better to update FAQ/FAQ.requiredlibraries.
Kiyo
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Hi Frederic and other arm lovers,
I've put binary tarball on
http://www.kaffe.org/~inaba/kaffe-arm.tar.gz
It can be extracted to /usr/local/kaffe on your target machine, and
I've tested it works with my qemu environment.
Kiyo
___
kaffe
Hi Frederic
It's a real gcc-3.4.4 that i'm using.
In my case, gcc is 3.4.6
$ gcc-3.4 -v
Reading specs from /usr/lib/gcc/arm-linux-gnu/3.4.6/specs
Configured with: ../src/configure -v --enable-languages=c,c++,f77,pascal
Frederi ([EMAIL PROTECTED]) wrote:
I finally used kaffe that i've downloaded from ricoh.co.jp and while
excuting it with a simple helloworld, i've got the following error:
Illegal Instruction
So i think that the error is not due to classpath or other (not a java
error)
How can i found what is the
Frederic,
I've seen in the past days that JIT was now working for ARM with Kaffe.
But i'm wondering what is exactly going on with JIT and JIT3. Are they fully
working?
Nothing works perfectly. If you only needs kaffe's regression test
level quality, JIT is very close. (Floating point still has
Steve,
These are my experiences based on QEMU for ARM926EJ-S simulation.
Of course for the ARM926EJ-S, there is no need for a jit since it can run Java
bytecode natively.
Touche ;-
As you know, I am not so familiar with ARM family. I simply copy the
message displayed when linux starts. So
Kiyo Inaba wrote:
just now. I will invoke another configure run (on this emulated machine
it may take one hour) with '--with-libffi' options.
Even with '--with-libffi' option, arm/jit with gcc-4.1 does not work.
It got same error message with sysdepCallMethod version.
While playing with jit3
Dalibor wrote:
1) Why it does not work with newer version of gcc?
off the top of my head, i'd guess ffi changes.
While in Shikansen (Japanese version of ICE, or for us, ICE is your
version of Shinkansen ;-), I tried to see what is the difference
between old gcc generated and new gcc generated
Short report,
Kiyo Inaba wrote:
And I agree
that, it should be ffi related. Some compiled method are ok but some
are not good. In high speed train, since we still don't have good
internet connection and 'apt-get' does not work, I installed libffi.deb
just now. I will invoke another configure run
I said,
Since I don't want to see 'jit on arm every few months', I started
to work with emulators...
After several days of hastle, I finally make kaffe jit works for
arm with only one modification (sys1 macro definition). It is very
important to use gcc-2.95, and don't specify 'with-staticvm'
When I specify '--with-static{bin,lib,vm}' for CVS-head the generated
code does not work. This was happened for ia32/linux and several other
ports.
When I specify only --with-staticvm, I got
-
Failed to locate native library
Riccardo wrote:
Dalibor Topic [EMAIL PROTECTED] wrote:
Alternatively, we could remove GNU Classpath from our tree, and require
the user to build it first, and then build Kaffe using that version. I
do not know if jikes can parse bytecode from compilers for Java 1.5, but
that's the only way I'd
Dalibor wrote: (slightly change the order of sentences)
Kiyo Inaba wrote:
But, as a matter of fact, this patch does not solve my problem for
making arm/linux/jit works again. Or even, v1.3 of 'md.c' (not
using ARM_NR_cacheflush) does not solve it.
Since Sascha's report indicates (even he does
Hi,
Since I don't have enough time to do the compilation itself (and of
course invoke regression test) right now, but I hope I can continue
this effort for this weekend.
Since, it's friday, and not so many meetings (thanks someone its friday),
I can continue my work for compilation. There are
Hi all,
Since I usually don't test kaffe snap on arm based machines, but see
several ML messages saying, 'kaffe can not be compiled for arm, and
so on' or 'kaffe awt does not work for arm, and so on' several times.
So, I spent some time to get some 'portable' environment to test kaffe
for arm.
Hi Dalibor,
Dalibor wrote:
Kiyo Inaba wrote:
Anyway, I try to separate classpath build from the entire kaffe
build, and let you know when finish.
Great, thank you!
As I said earlier, I tried to make classpath compilation separated
from kaffe's main compilation. I tested this with i386/{netbsd
Hi Dalibor,
I think the best way forward there is to remove the external libraries
from the Kaffe tree,
so that we no longer need to have a separate KAFFE_CFLAGS and a CFLAGS
variable,
since we'd no longer have sub-configures to invoke. That would allow
simplifying the configure
script further,
Hi,
For the last several monthes, kaffe configure command can not handle
'-C' option (to enable using cache for configure) properly. In this
weekend, I finally found some extra time to trace back why it happens.
After checking with several old snapshots, and seeing CVS repository,
I noticed
Hi everybody,
Hi Jim and everybody,
Thanks Jim to keep kaffe.org up and running.
So I'm assuming that the project isn't dead, it's just somewhat dormant.
It's been somewhat dead/dormant throughout much of it's history, but
it's still here, isn't it? :-)
Yes, it's still here! As I posted
I was reported by weekly regression that CVS head can not be compiled for
m68k/linux. Maybe too old version of gcc (2.95.4) used on this platform?
---
gcc -DHAVE_CONFIG_H -I. -I../../../include
Dalibor Topic wrote:
Dalibor Topic wrote:
I'll update cvs head to use autoconf 2.61, and hope that fixes the
issue on ksh on netbsd 1.6.
Done now, could you give it a try?
I submitted configure with generated file by autoconf 2.61 locally, but
the result is
Hi,
For the last two months I got build failure on m68k/NetBSD-1.6. After
reporting the failure for m68k/linux, I started to tackle this problem.
Since it has been found from November 9th, I traced back ChangeLog and
noticed AC_CHECK_FUNCS_ONCE or AC_CHECK_HEADERS_ONCE are one possibility.
So, I
Thanks for the patch, Kiyo. Since the code comes from GNU Classpath,
I'd like to see it fixed upstream,
Thanks, I can wait for this happen on Classpath.
# BTW, Tim Bevan's patch with void cast worked for m68k/linux.
as well. I've read
http://citeseer.ist.psu.edu/928.html
a while ago, and it
Since it has been found from November 9th, I traced back ChangeLog and
noticed AC_CHECK_FUNCS_ONCE or AC_CHECK_HEADERS_ONCE are one possibility.
So, I installed new autoconf, and so on, and regenerate autoconf staffs
without using these two macros (takes time...), and voila..., the build
works for
Hi, Happy new year everyone!
For the last several weeks, I noticed kaffe weekly build can not be made
on m68k/linux. Today, I can spend some time to check why it happens.
Mainly this is because compilation flag '-Werror' has been added to
compile 'java_nio_MappedByteBufferImpl.c'. After adding
Latest CVS head was failed to be built.
Making all in external/classpath
make[2]: Entering directory
`/proj/kaffe/kaffe-snap-060720-linux/libraries/javalib/external/classpath'
make[2]: *** No rule to make target `all'. Stop.
Maybe some failure for the recent classpath merge?
Kiyo
I said,
Unfortunately your mod (to add jni.h for the file) does not solve
the problem.
The failure because of new syntax which is not compatible with gcc
for nb1.6 is used. I add comment in Bugzilla about that.
If no objection, I will checkin this mod later (maybe when I go back
to Japan).
Kiyo
Dalibor,
I've added an explicit include statement for jni.h, where jvalue is
defined to the file. That should fix that particular problem.
Unfortunately your mod (to add jni.h for the file) does not solve
the problem. I am not so sure whether this is OS version specific or
not. I use NetBSD1.6
Hi,
Looks like 1.1.7 just released can not be compiled on NetBSD with intrp
engine. The other engines, jit3 and jit, are ok.
The error is when compiling 'methodcalls.c', I got
../../../../kaffe-1.1.7/kaffe/kaffevm/intrp/methodcalls.c: In function
`engine_callMethod':
Hi,
Latest build fails if I specify --with-glibj-zip. It does not import glibj
and tries to generate tools.jar (of course it can not be done, since we
don't have glibj)
Kiyo
___
kaffe mailing list
kaffe@kaffe.org
Hi all,
After the introduction of fastjar, 'libz' library becomes mandatory,
according to my understanding.
But still in 'FAQ.equiredlibraries', statement says
If you want to work with ZIP or Jar files,
I think this document should be updated.
Kiyo
Hi Dalibor,
I am now checking this with several different CPU/OS right now.
(As you know, some machines take long long time to do that ;-)
Thanks.
For the time being, regression against rc1 looks ok for both m68k/
linux or netbsd, and ia32/netbsd. Testing for sh3/linux (or possibly
netbsd)
Hi,
Thanks to improve using fastjar for kaffe. After this introduction,
yesterday is the first time for my regression test. And I noticed,
one of my build environment does not have zlib.h installed.
And of course configure script checks this as
checking zlib.h usability... no
checking zlib.h
.
Kiyo Inaba wrote:
Dalibor wrote:
In particular since you are compiling kaffe for m68k-ecos, I'd suggest
turning gcc's optimisation off (CFLAGS=-O0), as people have reported
various problems with m68k and older gcc version being overeager on
optimisation. I've CC:ed Kiyo, who I recall having worked
Hi Madhusudan
G.Madhusudan wrote:
Can someone explain why the SP_OFFSET is different in these two files
for the ARM (non XSCALE) case?
The SP_OFFSET defined in threads.h should be wrong. But anyway it was
overwritten by md.h, and may not cause any trouble, except for someone
try to read the
Dalibor wrote:
Kiyo Inaba wrote:
But, it works fine for 'vmintegration.info', but still 'hacking.info',
'hacking.info-1' and 'hacking.info-2' are missing. The creation date
suggests haking.* needs some special treatment.
thanks for the update, Kiyo. I'm not seeing any problems during my
builds
Hi Dalibor,
dalibor topic wrote:
I've checked in a fix for that now, which uses a trick: instead of
copying plain gnu classpath CVS files over, it first builds gnu
classpath,and creates a distribution tarball from the cvs checkout, and
then copies those files over. That automatically ensures
When a build was made with '--with-glibj-zip' option, do we still need
gen-classlist.sh script to be invoked? I think this is only needed
to build classpath jar file, and takes long long time ;-
Kiyo
___
kaffe mailing list
kaffe@kaffe.org
Kiyo Inaba wrote:
Dalibor wrote:
Kiyo Inaba wrote:
2) With older version of jikes (1.19) the option 'no-shadow' is not a
valid option, and invocation of jikes failed with this SNAP. I hand
edit Makefiles (and TestScript) and got proper result.
Checking the version of jikes while
Hi Dalibor,
Dalibor wrote:
Kiyo Inaba wrote:
For the latest snap (051208), I got two problems with jikes.
1) '--with-jikes' option of configure script got slightly different
semantic. Until recently, the option can get parameter for the path
of jikes, but this snap did not pass
Dalibor Topic wrote:
Ito Kazumitsu wrote:
Sorry for missing your message. I did not think that would be a
problem to me.
Same here ;(
It's ok. Even I did not have confidence whether this bug is only for
*BSD, or more general. Whenever I found a bug for a port, I compare
it with RH8.0 or FC3,
For the latest snap (051208), I got two problems with jikes.
1) '--with-jikes' option of configure script got slightly different
semantic. Until recently, the option can get parameter for the path
of jikes, but this snap did not pass parameter for this option to
sub configure. This makes
Hi,
Since I got both m68k/netbsd and m68k/linux working, I restarted to
reduce the number of failure in regression test.
First test failed for both netbsd and linux is 'RefTest.java', and
I noticed it is very simple why it fails.
In the source we have
Watchdog dog = new Watchdog(1);
and
I wrote:
and the reason why I put -O1 in spite of -O2 is
-O1 makes firster executables than -O2 (if I remember correctly).
I tested -O1 and -O2 against latest snap, and the elapsed time needed
for 'make Check' (m68k/netbsd/jit3) are
-O1: 10:06:34
-O2: 10:41:15
Of course, this includes
Hi Kaz,
The building of recent CVS version fails with the following message.
You met same problem as I faced (and reported titled 'build failure for
nb1.6') several days ago.
| However, all GNU distributions should come with prebuilt info files,
| thus makeinfo should not be needed. If you
Hi Kaz,
Using the following poor man's ecj,
$ cat bin/ecj
#!/bin/sh
exec /usr/local/kaffe/bin/kaffe \
-classpath $HOME/javalib/org.eclipse.jdt.core_3.1.1.jar \
org.eclipse.jdt.internal.compiler.batch.Main \
$@
That's a good news! Could you please add something in
Hi,
I have not yet reviewed the reason but latest snap (05/12/01) gets one more
fail compared with previous (05/11/24) snap. Ths test is 'ExecTest.java' and
the failure is timeout.
Since it outputs nothing, I am wondering exec/waitFor pair may get some
faulty behavior in the last one week for
Hi,
The latest snap (05/12/01) failed for build on machines which does not
have TeX.
The error messages are
if /usr/local/bin/bash
/usr/proj/src/kaffe-snap-051201/libraries/javalib/external/classpath/missing
--run
Hi Dalibor,
The original post is interesting (in some sence) for me, but first
I try to answer very trivial point, since I was called.
In particular since you are compiling kaffe for m68k-ecos, I'd suggest
turning gcc's optimisation off (CFLAGS=-O0), as people have reported
various problems with
Hi Guilhem,
You can join us on #kaffe (irc.freenode.net). We made experiments on
m68k but I don't exactly remember the state.
The port m68k (for linux or netbsd) has been tested with MC68030, rather
than MC68000. I have no info whether kaffe works with MC68000 or CPU32
based processors.
Kiyo
Error: switchcheck is not a recognized flag for controlling pedantic
warnings.
Error: shadow is not a recognized flag for controlling pedantic warnings.
use: jikes [options] [EMAIL PROTECTED] file.java...
You are using too old version of jikes. Before jikes-1.19, these
options are not accepted,
After struggling to get latest jikes on slightly older NetBSD machine,
I finally get regression test against 05/11/03's snap.
Failed programs are
jit3: ProcessTest.java
jit: FPUStack.java, ProcessTest.java
intrp: ProcessTest.java
much better than before.
For FPUStack some values are 0.0 rather
1 - 100 of 292 matches
Mail list logo
