Re: Compilation Problems with libjava

[Dhek Bhun Kho <bhun at chello dot nl>]

Hello Andrew,

>  > I was going to try and hack the makefiles to just compile the
>  > things that are tightly integrated into GCJ into the libgcj.so
> I don't understand this.
Well I have been spending quite some time primarily on getting existing
code compiled and trying to find out what's peculiar to GCJ. Like a few
weeks ago I reported that it was really a nuisance for the org.*.*
classes to be present. It was on part caused by my ignorance. 'cause I
did get to compile a Ant binary with classes from xerces and xalan
linked in. 

Summarized: 
It's impossible to replace faulty classes when everything is compiled
into one huge shared object. 

Note:
I was wondering whether using the naming scheme as specified in the gcj
manual would help out on this. This does create extra work when linking
because you have to specify each and every dso like -l-java-lang
-l-java-util .. you get the point.

Questions:
1. But doesn't this make it easier to replace faulty libraries? Correct
me if I am mistaken. Like when a StringTokenizer is broken, replace the
object in the static library with ar, then regenerate  the shared
libraries. 
2. Would -fPIC prevent the need to relink every application linked
against the older versions?

Reason:
The first time I generated a dso named lib-org-w3c-dom with every
subpackge contained in it. This caused the duplicate key problem. I
wanted to do this at first because I didn't want to generate like 20+
dso's for just one source package. 

Second time around I generated each dso named after the package so I got
the 20+ dso's and just linked in the missing classes by specifying the
dso's that contained the classes under the org.w3c.dom.xx.xx namespace.
So it wasn't really necessary to splitt off the org-w3c-dom. (Shoot me)
Haven't had the opportunity yet to test the xml tasks.

Furthermore I have been looking into some other (gpl/apache) source
packages like JBoss and noticed that they _hardcode_ some references to
their own implementations into some javax.* classes. It's all a bit too
early for this I guess, but it can't do no harm to look at what's lying
ahead. I noted the part about cni because some classes from gcj are
implemented using c++ (nio I believe amongst others). 

I really can't help asking all the sily questions, but it's not easy to
figure from sources on the net. It's still quite a bit experimental for
me.