> > Now that you've gone through all that effort, classpath 0.04 has been
> > released and it can be compiled and built independently of a vm.
> > This means we don't have to provide a kissme specific version anymore,
> > we'll still have put the kissme VM files in front of CP files in the
> > classpath though.
> > So to simplify things, can you change the autoconf scripts to just take
> > one parameter that identifies the local classpath installation prefix
> > (eg /usr/) which will point us to $prefix/share/classpath/glibj.zip
> > for .java file compilation and $prefix/lib/classpath for shared libraries.
> I'll do this next time I'm doing configure stuff. At the moment, I hunting
> persistence/GC bugs.
The GC is frustrating because of the fact that we have to make sure we don't miss a live reference.
Another case is where the mark routine fails to mark a live object.
Another possible class of bug is an error in the actual heap allocation, compacting code, but I hope there isn't one in there.
> > How do programs know where to look for their libraries? How should kissme
> > be "configure"'ed such that it can find the shared libs?
> These are good questions. The answers depends on various things:
> * Should a kissme binary distro include GNU Classpath shared libs?
> If yes, I think kissme install should put them in GNU Classpath's
> standard place. If no, a kissme binary install will have a
> GNU Classpath build and install as a prerequisite. (AFAIK
> GNU Classpath doesn't have binary distros yet.)
I would like these requirements:
1. To build kissme -- Classpath source must be available
2. To run kissme -- Classpath binary must be installed
> * Should an uninstalled kissme build use GNU Classpath libs in their
> installed location or in the GNU Classpath build area?
If it is an uninstalled build, it is up to the user to specify the arguments on the command line and set LD_LIBRARY_PATH where appropriate.
But perhaps kissme should look in the default Classpath install locations first (for convenience). We shouldn't have any dependencies on the Classpath build area, if someone wants to do development work (don't want to overwrite the installed Classpath), they can just install to some arbitrary location under their home directory.
> * What about an installed kissme binary / shell wrappers?
They should expect Classpath to be installed in the default location (or otherwise they will have been built with a flag that indicates where to find classpath).
> On the technical side, the way that a binary looks for shared libraries
> is a bit platform dependent, but I think that "libtool" is supposed to
> help with that. In the short term, we can get it to work with a
> combination of flags to "ld" and LD_LIBRARY_PATH. For example, the
> flags to "ld" tell the kissme binary to look in $libprefix/classpath (or
> wherever). The LD_LIBRARY_PATH in the wrapper script could tell kissme
> to also look in the Classpath build areas, depending on where the copy
> of wrapper script lives; e.g. using the ksh "whence" built-in.
Ah, I didn't know you could tell ld this ( this gap in my knowledge was bothering me! )
In this case I think that an installed kissme would be linked such that it looked for libraries in $libprefix/classpath (but this would be overridable).
My problem right now is that I can't run the configure script with the 0.04 Classpath release. Which flags do I have to specify? Can I get away without having a kissme_classpath directory?
> > I'm thinking of resurrecting the support for loading classes from zip
> > files. I took it out because I was testing the pure java zip classes,
> > but it's too slow with an interpreted JVM.
But prior to this I'm perplexed by GC bugs!