Re: Current status of your swt-gtk package
* Joe Smith <unknown_kev_cat@hotmail.com> [2005-10-24 16:14]:
>
> "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
No. That's an old article and was written before gcj's Binary Compatible
ABI was implemented.
> 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.)
You'll notice in my comments that I say "using upstream's methods". I
guess I should have specified that we aren't modifying Eclipse's source
code here. We build Eclipse just like they do upstream but then take the
extra step of natively-compiling all the jars. gij (the interpreter)
intercepts class loading calls and checks a hash map (built by gcj-dbtool)
to see if it already has a .so for the class that is being loaded.
> 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?
No changes to Eclipse's class loaders (or those of any other app) are
necessary. This way, users can run with another JVM if they want and just
use the bytecode. For more informtaion, see Tom Tromey's article in the
latest Red Hat magazine (sorry, I don't have a URL handy but it was
reference in Mark Wielaard's latest blog entry which can be seen at
http://planet.classpath.org).
Andrew
Reply to: