This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: -findirect-dispatch: broken on Linux, working on Mingw?
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. The other thing then probably is libgcj.a. ld won't know what
to add to the binary (static linking), so I'm running into the "missing
references". At least that is my understanding now after you explained
indirect-dispatch. Makes all sense now ;-)
Yes, by manually adding the objects from libgcj.a, my little test
compiles with GCJ 4.3 too...
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? 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?
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. Also, libgcj.spec from GCJ 4.2 and 4.3 are
identical.
thanks
Marco