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

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.

Thinking some more, there is one possible advantage to using indirect
dispatch with static linking: it would allow you to call bytecode from
compiled code.  You'd still, however, need to be very careful about
building the executable.

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

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)

Andrew.