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

[Marco Trudel]

Andrew Haley wrote:
> 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.

I prefer compiling my jars into the binary instead of creating a shared 
lib for each jar (or one lib for all jars). Specially because I want to 
do it the same way on Windows as on Linux and on Windows, creating dlls 
is currently broken. Otherwise that would be an option.

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

Ok...

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

Attached:
newLib.txt: Compilation output with your *lib: ... line.
oldLib.txt: Compilation output with the original *lib: ... line.

I should mention that I work on 32bit Windows with a static GCJ rev 
122233. The libgcj.spec is used, I removed the *lib line and got another 
error.


thanks
Marco
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: newLib.txt
URL: <http://gcc.gnu.org/pipermail/java/attachments/20070309/7b6f9792/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: oldLib.txt
URL: <http://gcc.gnu.org/pipermail/java/attachments/20070309/7b6f9792/attachment-0001.txt>