Re: bc-abi2: large application handling

[Andrew Haley <aph at redhat dot com>]

Jakob Praher writes:
 > thank you Andrew for your replies so far.
 > 
 > Am Mon, den 11.10.2004 schrieb Andrew Haley um 17:29:
 > >  > * what are shared object files / what are executables?
 > > 
 > > I don't understand this question.
 > > 
 > I simply asked myself when one should generate an executable and when a
 > shared object, in that sense that strictly speaking every java class can
 > be used as a library. So I meant that making a big executable out of
 > many jar files doesn't make much sense, given that there is pretty much
 > library reuse in java projects. (for instance most java apps link to
 > log4j or jakarta-commons)

True.  Strictly speaking, exceutables as such are merely a
convenience.

 > >  > in java every class can be mainable, so how do you go for that when
 > >  > compiling so files - is the --main argument still the right method
 > >  > should. 
 > > 
 > > Shared objects don't have a --main.  You can invoke them with gij,
 > > which you give a class name whose main you wish to invoke.
 > 
 > ok. that's new to me.
 > how do you supply the so files then (using LD_LIRBARY_PATH?)

It's in the docs.  See 'Extensions' in gcj.info.

  > >  > with bigger classes, I get an internal compiler error. Is the usage
 > >  > simply wrong, or is that a bug in the compiler?
 > > 
 > > That would be a bug.  An ICE is always a bug.
 > ok.
 > The compiler failed only when generating an executable. Since the bug
 > was with a java.io class and read_zip_entry, I supplied the
 > $PREFIX/share/java/libgcj-3.5.0-abi.jar and it worked.
 > 
 > I am now wondering why it is searching for the core class
 > java.io.FilenameFilter in the system class path? Or does the compiler
 > need every class in .class format on the classpath?

gcj should automatically locate libgcj-3.5.0-abi.jar where it's been
installed.

Andrew.