"Andrew Overholt" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
* Joe Smith <[EMAIL PROTECTED]> [2005-10-22 14:51]:
>From http://www.backports.org/~mkoch/unstable/ eclipse_3.1-10.diff.gz it
>appears that first the (bootstrap) ecj compiler is built using gcj, then
>the rest of eclipse is compiled with the natively compiled bootstrap
>ecj.
Ok. The natively compiled ecj, does this then compile a non-native ecj?
If
so that kind of reminds me of the gcc boostrapping.
Yes. This is the procedure we worked out for bootstrapping Eclipse builds
for Fedora. I've actually found some issues with a natively-compiled ecj
being used for the rest of the Eclipse build so we do this:
1. build ecj to bytecode using gcj -C
2. use the resulting ecj to re-build itself (using upstream's methods)
3. use _this_ resulting ecj as the "javac" for the rest of the Eclipse
build procecudure (again using upstream's methods)
So basically the information in this article applies?
http://www.linuxjournal.com/article/7413
Have the necessary changes for eclipse submitted upstream? These changes are
so that eclipse is willing to load the precompiled shared libraries rather
than the jars it was expecting. (The jars would work, but using them defeats
the point of native compiliation.)
Also, one comment in the article I linked to notes that requiring changes to
custom class loaders to support native compilation is not a great idea. Is
there any way to modify gcj so that programs like eclipse need not have
their class loaders modified?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
