Supporting different runtime profiles

Mon Jul 2 13:50:00 GMT 2001

Tom wrote:
> Anthony> * a profile, FOO, is built by reconfiguring gcc/libjava in
> Anthony> the build directory gcc/$target/libjava/profiles/FOO.
>> I don't follow. Is this something you do by hand? Or is it something
> you do once when you configure all of gcc? E.g., with
> --enable-libgcj-profiles=x,y,z? How will mutlilibbing be handled?

Right, you use --enable-java-profiles=x,y,z. These profile directories are
automatically configured at configure time. Multilibbing should work as
usual, that is, you'll get multilibbed versions of all of these libraries.
> I guess one thing that will be important is for us to identify the
> necessary configuration points, and also to document how they
> interrelate. E.g., if you don't want reflection data, then you might
> as well disable the interpreter and JNI.

Some of Sun's profiles assume no reflection but imply interpreter support.
> This is the one piece that might not be implementable.
> Maybe we could do it by putting a lot of work into gcjh. It could
> read every variant of a class and then output the appropriate header.
> Given the current state of gcjh I'd guess that this would be a lot of
> work.

Hmm --- you're right. I didn't even think of the gcjh headers... :-(
AG