Re: -findirect-dispatch: broken on Linux, working on Mingw?

[Andrew Haley <aph at redhat dot com>]

Marco Trudel writes:
 > Andrew Haley wrote:
 > > Marco Trudel writes:
 > >  > Andrew Haley wrote:
 > >  > > Marco Trudel writes:
 > >  > >  > Hey all
 > >  > >  > 
 > >  > >  > I once started a discussion that ecj1 can't be compiled for a host=Linux 
 > >  > >  > target=Linux static gcj: http://gcc.gnu.org/ml/java/2007-01/msg00082.html
 > >  > >  > Back then, no one knew why the error occurred. I think I now stumbled 
 > >  > >  > over the answer:
 > >  > >  > 
 > >  > >  > Having Test.java as a simple "HelloWorld" and working with the compiled 
 > >  > >  > class:
 > >  > >  > 
 > >  > >  > On Linux:
 > >  > >  > ---------
 > >  > >  > 
 > >  > >  > static-gcj-for-lin Test.class --main=Test -findirect-dispatch
 > >  > >  > -> /tmp/ccq2qpMg.o: In function `main':cc3Fk97a.i:(.text+0x30): 
 > >  > >  > undefined reference to `JvRunMainName'
 > >  > >  > collect2: ld returned 1 exit status
 > >  > >  > 
 > >  > >  > static-gcj-for-win Test.class --main=Test -findirect-dispatch
 > >  > >  > -> works
 > >  > >  > 
 > >  > > 
 > >  > > I just can't imagine how indirect dispatch is ever going to work with
 > >  > > static linking.
 > >  > 
 > >  > I don't know what indirect dispatch exactly does.
 > >  > But I know that it perfectly works with gcc 4.2. So it looks to me
 > >  > like it's a regression.
 > > 
 > > Indirect dispatch works by postponing all linking until runtime:
 > > whenever a class is referenced, libgcj searches all the jarfiles and
 > > shared libraries it knows about to satisfy the reference.  So, no java
 > > libraries (apart from the dummy libgcj-bc.so) are linked into the
 > > executable.  With static linking, this will cause problems, because
 > > the linker can't possibly know what compiled code it needs to link
 > > into the executable.
 > 
 > I usually put all the needed source into the binary, so that won't be a 
 > problem.

OK.

 > > It is possible that this might work by accident, if you just happened
 > > to include the classes you were going to need.  Or, maybe very careful
 > > manual linking would allow you to add all the classes you knew you
 > > were going to need at runtime.  But in that case you might as well
 > > link without indirect dispatch.
 > 
 > I need indirect-dispatch for compiling large applications. They
 > usually have a couple of jars. These jars then reference a ton of
 > other jars which are never used, but referenced anyhow. So I either
 > need them to compile the jars, or ignore the references. If I
 > search and download the missing jars, they usually too reference a
 > bunch of other jars and so on...  So I go for ignoring the
 > references and use indirect-dispatch. Is there a better way to
 > solve this problem?

Yes, but you know already.  Indirect dispatch and shared libraries is
the right answer to this problem.

 > Solving all dependencies only needs very much time and creates huge
 > binaries...

 > >  > > It certainly isn't designed to, and there are lots of
 > >  > > good technical reasons for believing it can't.  The linker can't see
 > >  > > the symbols indirect dispatch uses, so can't find out what objects need
 > >  > > to be linked into the program.
 > >  > > 
 > >  > >  > Any direct ideas? Otherwise I'll add a bugreport.
 > >  > > 
 > >  > > Short of fixing Mingw to work properly with shared libraries, no.
 > >  > 
 > >  > It works in GCC 4.2 for Linux and Mingw as well as in GCC 4.3 for Mingw. 
 > >  > So it more looks like Linux should be fixed instead of Mingw broken to 
 > >  > be consistent ;-)
 > > 
 > > The point of indirect dispatch is to be able to upgrade the libraries
 > > on a box without recompiling any of the applications. or indeed any
 > > other library.  You can even replace libgcj itself with a new library,
 > > and the precompiled applications continue to work.
 > 
 > So, the missing references make sense. But why did it work in GCJ 4.2?

Probably because of the libgcj-bc library changes.

 > Maybe it was intentionally but broken in the mean time?
 > Or maybe the linker changed? I think I updated binutils for 4.3...
 > 
 > > However, if you really do want to do this weird thing, this link line
 > > in install/lib/libgcj.spec might work after a fashion:
 > > 
 > > *lib: %{static-libgcj:-non_shared -lgcj -call_shared;:%{s-bc-abi:-lgcj_bc;:-lgcj}} -lm   -lpthread -lrt    -ldl %(libgcc) %(liborig)
 > 
 > No, that doesn't fix it.

I tried it, and it works for me on GNU/Linux.  We need the output
using "gcj -v" to know why it failed in your case.

Andrew.