BUGS in kaffe.0.9.2

[Aleksey Sudakov]

Hi,

I played around with building kaffe on m68k-next-OpenStep4.2 and discovered  
several problems

First of all by default on NeXTSTEP/OpenStep ./configure come out with the  
following configuration:

On m68k
checking host system type... m68k-next-nextstep3
checking execution engine... intrp
checking library type... shared

On i386
checking host system type... i386-next-nextstep3
checking execution engine... jit
checking library type... shared

Frankly I don't believe that kaffe libraries build the way they are could be  
used on OpenStep as shared libraries. But this is a very long story, so any  
comments on how shared libraries organized in kaffe are very welcome. For now  
let's focus on a bug that comes right away after configuration.

BUG 1:
Makefiles that are generated result in the following error

true --def ./libnative.def --output-exp lib.exp --output-lib libnative.a  
--dllname libnative.o
touch lib.exp
ld -r -o libnative.o.0.92  -lm
ld: no object files loaded

This is because there is an erroneous "\" symbol at the end of line 99 in  
kaffe-0.9.2/packages/tjwassoc.co.uk/APIcore/lib/Makefile.in

After fixing this one could compile upto kaffe binary on m68k (on i386  
compilation will fail in trampoline.c. I could give more details as soon as I  
get to the office) and experience the following mess in  
kaffe-0.9.2/kaffe/kaffe/Makefile

BUG 2:
A. libraries reffered as libkaffe_<libname>.a while they created as lib<libname>.a
My guess this is a bug in configure or in Makefile.in in every  
tjwassoc.co.uk package.

B. -lkaffevm is included twice resulting in "multiple declaration..." error.

After fixing this one could make install, but kaffe wouldn't work because

/usr/local/bin/javac HelloWorld.java
Failed to locate native library in path:
        /usr/lib:/usr/local/lib
Aborting.

Here is my environment to make sure that this is a problem with shared  
libraries, not my environment

black> setenv
....
CLASSPATH=.:/usr/local/share/kaffe/classes.zip
KAFFEHOME=/usr/local/share/kaffe
LD_LIBRARY_PATH=/usr/lib:/usr/local/lib


So at this point I tried to build kaffe with static libraries. Apart from  
bugs mentioned above everything was smooth up to the linking of kaffe binary  
where I've got the following error:

/bin/ld: Undefined symbols:
_java_lang_reflect_Field_getBoolean
_java_lang_reflect_Field_getByte
_java_lang_reflect_Field_getChar
_java_lang_reflect_Field_getDouble
_java_lang_reflect_Field_getFloat
_java_lang_reflect_Field_getInt
_java_lang_reflect_Field_getLong
_java_lang_reflect_Field_getModifiers
_java_lang_reflect_Field_getShort
_java_lang_reflect_Field_setBoolean
_java_lang_reflect_Field_setByte
_java_lang_reflect_Field_setChar
_java_lang_reflect_Field_setDouble
_java_lang_reflect_Field_setFloat
_java_lang_reflect_Field_setInt
_java_lang_reflect_Field_setLong
_java_lang_reflect_Field_setShort
_java_util_zip_Adler32_update
_java_util_zip_Adler32_update1
_java_util_zip_CRC32_update
_java_util_zip_CRC32_update1
_java_util_zip_Deflater_deflate
_java_util_zip_Deflater_end
_java_util_zip_Deflater_getAdler
_java_util_zip_Deflater_getTotalIn
_java_util_zip_Deflater_getTotalOut
_java_util_zip_Deflater_init
_java_util_zip_Deflater_reset
_java_util_zip_Deflater_setDictionary
_java_util_zip_Inflater_end
_java_util_zip_Inflater_getAdler
_java_util_zip_Inflater_getTotalIn
_java_util_zip_Inflater_getTotalOut
_java_util_zip_Inflater_inflate
_java_util_zip_Inflater_init
_java_util_zip_Inflater_reset
_java_util_zip_Inflater_setDictionary

I failed to locate implementation of these methods also. Did I missed something?

This is basically how far I managed to get. It looks like kaffe is just one  
step away but I cannot get there without someone help. Unresolved issues are:

1. Not found functions in tjwassoc.co.uk packages.

2. Shared libraries mechanism and what it get's to have shared libraries  
working on OpenStep.
Food for thoughts: On OpenStep in order to build shared library one should  
compile with -shared flag and link using cc with -dynamiclib flag using  
frameworks instead of standard libraries. All of this calls for general  
revision of all Makefiles and configuration script. My skills here are very  
limited, so the best I could do is to provide complete "fixed" source tree  
and perhaps somebody will integrate it with mainstream distribution.

3. JIT om m68k. What it takes to implement JIT om m68k - the platform I am  
primary interested in?

Regards,
Aleksey