[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Current status of your swt-gtk package




"Andrew Overholt" <overholt@redhat.com> wrote in message [🔎] 20051024013005.GA9474@redhat.com">news:[🔎] 20051024013005.GA9474@redhat.com...
* Joe Smith <unknown_kev_cat@hotmail.com> [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?



Reply to: