The gcc build instructions must be updated for gcj-eclipse changes
before we can merge the branch.
A somewhat disconnected comment on the ecj-branch build process...
Are you planning to distribute ecj as a JAR file too? If so, there should be no changes to the documentation for building out of tarballs.
If you don't want to put the JAR in svn, To build from svn, a pre-existing GCJ would be necessary that can build ecj.
The build process should go like this:
- the gcc directory builds the bytecode->native compiler
- if there is a JAR, the ecj directory looks for ../gcc/gcj and uses that one to build the native compiler
- if not, the toplevel configury should pass the path to a GCJ somewhere and the ecj directory will use it to build the JAR. I think the JAR should be built in the build directory, unless --enable-generated-files-in-srcdir.
more on the third bullet: find the GCJ in the toplevel, as we do for C++ (grep for CXX= in the toplevel configure -- there is room for improvement but I don't think it's important). In the Makefile.tpl, add somewhere
and pass it down to ecj via HOST_FLAGS_TO_PASS.
Later on, ecj could even be bootstrapped using POSTSTAGE1_FLAGS_TO_PASS to point to the just build gcj and ecj. (How does gcj find the ecj to use? Might this require spec hacking?)
Yes, I plan on making an ecj jar download available.
In the near term I will put one on gcc.gnu.org (or elsewhere).
In the longer term I plan to get my ecj changes upstream, and then
we will be able to point people at the official eclipse.org download
(eclipse.org started releasing separate ecj jars recently).
Our particular ecj has a new driver which is tailored for gcc's use.
gcj on the branch looks for a program called "ecj1".
I just have this as a simple shell script, but there are any number of
ways to do this... eg you could compile ecj.jar to an executable using
This is found using the normal gcc specs approach. In a distribution
I'd expect ecj1 to end up in the gcc-lib dir. In my case I just have
it on my PATH.
We won't be including the ecj sources in the gcc tree. As I recall that
was rejected by the SC. So it will always be a separate download.
We also require a new version of gcjh. This is also written in java.
The code is part of GNU Classpath, but instead of struggling with the
bootstrap issues there, I'll again just make a downloadable jar.
Both ecj and the new gcjh can be run on any vm, including all the free
ones. I've built libgcj many times running these purely interpreted
and it is not painfully slow.
Subject: Re: [ecj] update build instructions to account for
> This is found using the normal gcc specs approach. In a distribution
> I'd expect ecj1 to end up in the gcc-lib dir. In my case I just have
> it on my PATH.
> We won't be including the ecj sources in the gcc tree. As I recall that
> was rejected by the SC. So it will always be a separate download.
The best thing would be if I could just "sudo apt-get install ecj". If
there are any differences between ecj and ecj1, we should provide some
kind of wrapper. A nice possibility, would be to support dropping the
downloaded JAR somewhere in the tree where it installs correctly and
automagically. This would not be against the SC decision.
> Both ecj and the new gcjh can be run on any vm, including all the free
> ones. I've built libgcj many times running these purely interpreted
> and it is not painfully slow.
Cool, though not unexpected because the code generation of Java
bytecodes is not that hard (apart from the unreachable and uninitialized
Maybe a --with-installed-ecj-jar=/path option would be good.
Then a distro like fedora could build gcj by pointing it at
an already-installed ecj; we could install a little sh script
in the right place that would run gij properly.
Subject: Bug 28938
Date: Wed Oct 18 23:36:32 2006
New Revision: 117868
* doc/install.texi (Prerequisites): Mention ecj1.
(Configuration): Move --with-java-home to libgcj-specific
section. Document --with-ecj-jar.
Note that this isn't quite fixed yet, as we haven't documented
how to handle gcjh.
I think this is fixed now.