This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: If you don't have a previous incarnation of GCJ installed...


Zack Weinberg wrote:

> > My preferred solution is for libtool to stop doing silly tests! (there has
> > never been a GCJ that doesn't support "-c -o"), but don't think Oliva liked
> > that idea. Ideally we could put a flag in ltcf-gcj.sh that tells it not to
> > bother, but I don't see an obvious way to do that with the current libtool.
>
> I s'pose you could have configure edit the generated libtool after
> LT_AC_PROG_GCJ is done.
>
> _My_ recommended solution would be for "class foo {}" not to require
> any external data in order to generate an object file, but I have no
> idea what causes the requirement; maybe this is genuinely necessary.

In Java, "foo" implicitly extends java.lang.Object, so GCJ must load at least
that class in order to determine layouts for fields, vtables, etc. If Object
exists as a class file, then it should be sufficient to load that class file
only (although maybe the current GCJ does too much work, I havn't checked), but
if Object is only found as a .java source file, then the parser must of course
load and parse all its dependencies as well. You can see this effect as libjava
builds - the first few files compile rather slowly, but things soon speed up
once .class files exist for the majority of the dependencies. Eventually we'll
hopefully have GCJ work like a real java compiler, and spit out .class files for
each dependency as it traverses them, which will further speed up the build.

regards

  [ bryce ]



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]