compilation problems with ecj.jar

[Marco Trudel]

Andrew Haley wrote:
> Marco Trudel writes:
>  > Andrew Haley wrote:
>  > > The *real* cause is that, for some reason, gcj isn't being passed the
>  > > correct path to libgcj.jar in the host system.  Instead, this happens:
>  > > 
>  > > jc1 /mnt/zebedee/aph/gcc/trunk/libjava/.././libjava/../ecj.jar \
>  > >  -fhash-synchronization \
>  > >  -fno-use-divide-subroutine \
>  > >  -fuse-boehm-gc \
>  > >  -fnon-call-exceptions \
>  > >  -fkeep-inline-functions \
>  > >  -quiet \
>  > >  -dumpbase ecj.jar \
>  > >  -mtune=generic \
>  > >  -auxbase ecj \
>  > >  -g \
>  > >  -O2 \
>  > >  -version \
>  > >  -ffloat-store \
>  > >  -fomit-frame-pointer \
>  > >  -findirect-dispatch \
>  > >  -fbootclasspath=./:/tmp/prefix/share/java/libgcj-4.3.0.jar \
>  > >  -o /tmp/ccD80X4c.s
>  > > 
>  > > Note that the bootclasspath at this point is wrong: there's no
>  > > libgcj.jar in the install dir yet.  The first "./" item in the string
>  > > is wrong because the .class files we need are no longer in the build
>  > > dir: they're in the srcdir.
>  > > 
>  > > This oughta do it:
>  > > 
>  > > Index: Makefile.am
>  > > ===================================================================
>  > > --- Makefile.am	(revision 120638)
>  > > +++ Makefile.am	(working copy)
>  > > @@ -670,7 +670,7 @@
>  > >  ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) -Djava.class.path=$(ECJ_JAR)
>  > >  else !ENABLE_SHARED
>  > >  ## Use ecj.jar at compile time.
>  > > -ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR)
>  > > +ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) -fbootclasspath=$(BOOTCLASSPATH)
>  > >  endif !ENABLE_SHARED
>  > >  
>  > >  ecjx_LDADD = -L$(here)/.libs libgcj.la
>  > > 
>  > 
>  > No, still the same:
>  > /home/Marco/Desktop/compile-lin-lin/gcc-build/gcc/gcj 
>  > -B/home/Marco/Desktop/compile-lin-lin/gcc-build/i686-pc-linux-gnu/libjava/ 
>  > -B/home/Marco/Desktop/compile-lin-lin/gcc-build/gcc/ -ffloat-store 
>  > -fomit-frame-pointer -g -O2 -o ecjx -findirect-dispatch 
>  > --main=org.eclipse.jdt.internal.compiler.batch.GCCMain 
>  > /usr/local/src/gcc/libjava/.././libjava/../ecj.jar 
>  > -L/home/Marco/Desktop/compile-lin-lin/gcc-build/i686-pc-linux-gnu/libjava 
>  > -L/home/Marco/Desktop/compile-lin-lin/gcc-build/i686-pc-linux-gnu/libjava/.libs 
>  > ./.libs/libgcj.a 
>  > -L/home/Marco/Desktop/compile-lin-lin/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src 
>  > -L/home/Marco/Desktop/compile-lin-lin/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs 
>  > -lpthread -lrt -ldl 
>  > -L/home/Marco/Desktop/compile-lin-lin/gcc-build/./gcc 
>  > -L/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/i686-pc-linux-gnu/bin 
>  > -L/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/i686-pc-linux-gnu/lib 
>  > -lgcc -lc -lgcc
>  > gcj: Internal error: Segmentation fault (program jc1)
>  > Please submit a full bug report.
>  > 
>  > Maybe I patched the wrong Makefile.am? I patched the one in the libjava 
>  > dir...
> 
> And you did run automake afterwards?

What is automake for? I tried to do a new gcj compilation. I assume that 
will automatically use the new Makefile.am.


>  >  >  > BTW,l there are more problems with compiling ecj.jar for
>  >  >  > cross-compiling. Creating a host-linux, target-windows GCJ will
>  >  >  > create a ecj.exe what is definitely the wrong thing to do.
>  >  >
>  >  > It's the right thing to do.  You have to build the ecj.exe for
>  >  > GNU/Linux as a separate step when building the GNU/Linux native
>  >  > compiler.  If you don't want ecj.exe for the target, don't include
>  >  > ecj.jar in the build tree.
>  > 
>  > What do I need a "exe" for on Linux?
> 
> It's a Windows executable that compiles .java -> .class.  If you're
> going to compile Java source on Windows, you'll need it.

But if I'd like to compile Java source on Windows, I would build a 
host=Windows target=Windows gcj. In my case, I have no use for ecj.exe 
since the a compilation happens on Linux.


> If you want to compile Java source on Linux, even if your target is
> Windows, you must build a Linux *native* compiler to get ecj.exe.

Isn't that somewhat senseless? If I only need a host=Linux 
target=Windows compiler, I also have to compile a host=Linux 
target=Linux gcj just to get my ecj and be able to compile .java source 
files on Linux?
But I get a ecj.exe for Windows that I don't need on Windows since my 
gcj only runs on Linux?
Where is the advantage of getting ecj for Windows? What could it be used 
for there? I'm sorry if I turn in circles, but I really don't see it. 
After all, I want to compile .java and .class files on Linux and deploy 
the created binary for Windows.


>  > If I create a gcj with host=Linux and target=Windows, I'd assume
>  > that I get a "ecj" binary for Linux that compiles for Windows.
> 
> And you'd assume wrongly.

So you tell me :-) But I really don't understand it...

>  > All other created binaries (gcc, gcj, objdump, ...) are also for
>  > Linux and not exes.
> 
> gcj-dbtool?  grmic?  gjar?  etc.  All for the target machine.

They compile for the target but run on the host. ecj.exe runs on target 
and compiles target-independent (I guess).


>  > If I get a ecj.exe, what can I do with it? I wont be able to
>  > compile .java files on Linux and its useless on Windows as far as I
>  > can see. But I'd be glad to learn better...
> 
> You need it for the Windows compiler.

Which Windows compiler? I have no Windows compiler if I build a 
host=Linux target=Windows gcj?!


thanks
Marco