Compilation Problems with libjava

Mon Jan 6 11:11:00 GMT 2003

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.