Brian> I think as far as CVS goes we could set it up so that the ,v
Brian> files from Classpath's tree get copied over to cygnus regularly
Brian> in the libjava directory of libgcj.
No, we can't do that. This approach fails to consider branches in our
repository. It also fails if anybody ever commits to any of the files
we just copy over.
However if we don't have a shared source tree we can do periodic
imports in one direction or another. I'd prefer to avoid this (since
I am the most likely candidate for doing the work :-).
Brian> One of the technical aspects to overcome is that libgcj can be
Brian> treated sort of like a VM which has special needs within the
Brian> usual culprits like java.lang.ClassLoader. There are also
Brian> various gcj specific features like eCos, gettings system
Brian> properties from GCJ_PROPERTIES, etc. to consider.
eCos is just another port. Nothing special there (it looks special,
because we implemented this in an odd way. Yet another thing to clean
up...).
libgcj really is a VM. We have an interpreter now (works only on x86
at the moment). We have (or should have, someday) all the other bits
associated with a VM.
Our goal has always been a complete system. That is why the VM and
runtime bits of libgcj aren't deeply separated from the class library
implementation. That is also why we feel free to use CNI instead of
JNI in our implementation.
(A brief note on JNI and libgcj: we realize that JNI is important.
CNI is more useful to us, but we don't expect the world to switch
over. It's just that we have had higher priorities than implementing
JNI, so it has languished. This is going to change in the
not-too-distant future. Well, it will probably change -- I'm slated
to work on it, but of course emergencies and such can alter our
course.)
Brian> I can't build libgcj at the moment, missing rpath on my system.
There is a line in Makefile.in that looks like this:
$(LINK) -rpath $(toolexeclibdir) [ ... elided ... ]
For some reason, $(LINK) is empty in your Makefile. The "-" is
swallowed by make (that is why the error code is ignored), and "rpath"
is run as a command.
The question is, why is LINK empty? In my source tree it is defined
with a rather lengthy value (starting $(LIBTOOL) --mode=compile ...).
Did you re-run automake or something like that?
Which release are you using?
Needless to say, I've never seen this bug before.
Tom
