I've been spending a little time working on the build process and I am happy
to report that I was able to get everything to build (almost). I'm now the
proud owner of a glibj.zip file that is 449,109 bytes -- about 5% of the
size of Sun's latest runtime library. Way to go guys. Just say no to
bloat.
I had to make a few changes in order to make things work for me. If they
break things for you, I apologize in advance. Here are some of my
findings/fixes:
-- java.lang.Float/Double: Yes, these had problems. The "TYPE" variable
decl/init was commented out, which broke things, plus these did not have a
package statement. I fixed both of these problems.
-- You have to copy all of the files in the vm/reference hierarchy into the
main class tree. This is currently a manual process. In the future, this
should be taken care of by the configure script which should copy in the
right files based on the VM selected. If you are in the toplevel dir of the
classpath package, something like (cd vm/reference ; tar cf - * ) | tar xvf
- should do the trick.
-- I added the parts of security that are compilable into the build. This
allows us to compile items that require that Permission and subclasses exist
in order to compile, but not necessarily that they work. This helps us to
be 1.2 compatible.
-- If you do --enable-maintainer-build you need JavaDeps. My copy of
JavaDeps has problems. In particular, it fails to recognize that certain
non-fully-qualified classes are really in java.lang and the .deps file it
generates puts a space after the line continuation character for the STUBS
declaration, meaning make bombs miserably. I've been fixing that manually.
As for the fully qualified problem, I just made manual modifications to the
classes I was having problems with (which was only a couple). Also, the
deps.sh script assumed jdeps was in a specific place. I changed it to
merely assume it is in your PATH, which is probably still not the greatest
idea. configure should check for this. Brian, I seem to recall that you
did some hacking on JavaDeps. Do you have a private version that fixes
these problems I could use?
-- make clean doesn't work right. This needs to be fixed.
-- Check out lib/standard.omit. This is a list of things that are currently
not being built. I can't explain them all, only the ones I added.
java.lang.Character has a problem with the JavaDeps parser. I believe it is
the same problem I corrected in StreamTokenizer. Namely, that the '\u000d'
construct exists. I changed it to '\r' in StreamTokenizer and it worked. I
didn't modify Character since the class is complex and I really don't
understand it enought to be making random mods.
-- GtkToolkit and Test in the GTK peer implementation didn't compile. I
think this has something to do with the fact that we don't have a working
java.awt yet. Anyhow, this is still a work in progress so I removed them
from the build. Otherwise the GTK peers built perfect, which is great for
something that isn't totally done yet. I'm gonna get the GTK+ CVS latest
and greatest soon so I can play with this super cool stuff. These are fully
Gnome integrated right?
-- I upgraded us to the latest libtool which supposedly has the interlibrary
support.
-- BTW: you have to build glibc.zip yourself. The raw class files get built
to lib, but aren't packaged into a zip file.
--
Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
