Re: Compilation Problems with libjava

[Andrew Haley <aph at redhat dot com>]

Dhek Bhun Kho writes:
 > 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. 

Where's the problem?  You just relink the shared object with the fixed
version of the class.  I don't think anyone here want to see a
situation where anyobe is using a broken version of libgcj and a bunch
of dynamically linked patch classes.  This would not be a recipe for
stabililty and reliability.

 > 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. 

No problem there.

 > 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. 

Fair enough.

My problem is, I suppose, that I don't really understand what problem
you're trying to solve.  If libgcj is buggy, we fix the bugs.

 > 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.

Is it really necessary to use a bunch of DSOs to do this?  I can't
think of any reason that you shouldn't merge these together and
include them on your link line.

Andrew.