Re: PATCH: Building libgcj with --disable-interpreter fails

[Andrew Haley <aph-gcc at littlepinkcloud dot COM>]

Rainer Orth writes:
 > Andrew Haley writes:
 > 
 > > Rainer Orth writes:
 > >  > I've recently tried to get libjava to build again on mips-sgi-irix6.5.
 > >  > After working around PR libgcj/28190 with a fixincludes hack, I had to
 > >  > fix two problems:
 > >  > 
 > >  > * I need a new mips-sgi-irix6* clause in configure.host to set the correct
 > >  >   sysdeps_dir and disable the interpreter (which cannot work since only the
 > >  >   O32 ABI has closure support in libffi):
 > >  > 
 > >  > Thu Jun 28 12:31:42 2007  Rainer Orth  <ro@TechFak.Uni-Bielefeld.DE>
 > >  > 
 > >  > 	* configure.host (mips-sgi-irix6*): Set sysdeps_dir.
 > >  > 	Disable interpreter.
 > >  > 	
 > >  > Index: libjava/configure.host
 > >  > ===================================================================
 > >  > --- libjava/configure.host	(revision 126209)
 > >  > +++ libjava/configure.host	(working copy)
 > >  > @@ -254,6 +254,11 @@ EOF
 > >  >  	sysdeps_dir=x86-64
 > >  >  	DIVIDESPEC=-f%{m32:no-}%{!m32:%{!m64:no-}}%{m64:}use-divide-subroutine
 > >  >  	;;
 > >  > +  mips-sgi-irix6* )
 > >  > +	sysdeps_dir=mips
 > >  > +	# disable interpreter, no closure support for N32 and N64 ABIs
 > >  > +	libgcj_interpreter=no
 > >  > +	;;
 > >  >    mips*-*-linux* )
 > >  >    	sysdeps_dir=mips
 > >  >    	can_unwind_signal=yes
 > >  > 
 > >  >   I'm currently running a bootstrap on the 4.2 branch, where this patch may
 > >  >   be enough to get libgcj working again (as it did in 4.1).
 > >  > 
 > 
 > The 4.2 branch bootstrap finished with just the configure.host part
 > applied.  Unfortunately, testresults are terrible
 > 
 > 	http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00398.html
 > 
 > which is probably due to missing libffi support for the N32 and N64 ABIs.

Maybe, but I'm not sure that really explains alot of the compilation
failures.

 > Anyway, with this patchlet, libjava at least compiles, so I suppose it's ok
 > to commit to 4.2 branch and mainline?

Yes.

 > > Tom Tromey and I have looked at the patch, and we both hate the idea
 > > of scattering yet more #ifdef INTERPRETER over the gcj source.
 > > However, it's probably the best thing to do at the moment.  Please
 > > commit this patch.
 > 
 > I suppose you mean the whole patch, both the configure.host part and the
 > #ifdef INTERPRETER hacks?

I do.

 > >  > * The much bigger problem on mainline was that with libgcj_interpreter=no
 > >  >   several files didn't compile any longer.  By trial and error I've
 > >  >   determined the following patch which fixes the compile problem.
 > >  >   Unfortunately, libgcj.so doesn't link any longer (what a surprise :-),
 > >  >   and I don't know the code well enough to determine how to fix this.
 > >  > 
 > >  >   Since my IRIX hosts are quite slow, I tried to verify this patch on
 > >  >   i386-pc-solaris2.10 (libgcj builds, but fails to link due to PR
 > >  >   target/32462) and sparc-sun-solaris2.10 (libgcj builds, but fails to link
 > >  >   due to many missing symbols) with --disable-interpreter.
 > >  > 
 > >  >   What's the best way to approach this?
 > > 
 > > I've added a comment to the Bug.
 > 
 > I fear I've been unclear: there are two link failures involved here:
 > 
 > * PR target/32462 which is Solaris 10/x86 specific and independent of
 >   --disable-interpreter
 > 
 > * PR libgcj/32652 where even with my #ifdef INTERPRETER patch applied
 >   libgcj.so links successfully, but e.g. jv-convert fails to link due to
 >   many unresolved symbols:

 > ld: fatal: Symbol referencing errors. No output written to .libs/jv-convert
 > collect2: ld returned 1 exit status
 > make[3]: *** [jv-convert] Error 1
 > 
 > I fear there's no other approach than looking up every reference to those
 > symbols and see what can be done about them (like providing a dummy
 > replacement).

Fixing libffi?  It's probably easier.

Andrew.