Re: bootclassloader problem (gcc 4.0 regression)

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Wed, 2005-04-13 at 09:43 -0700, Per Bothner wrote:
> Mark Wielaard wrote:
> > This makes some
> > of the original hacks for class loading with old native gcj designed
> > programs more difficult/wrong.
> 
> But I'm not using any hacks for gcj.

Not hacks in your program. Hacks in libgcj for faking the system class
loader for pre-compiled native code (non-BC-compiled). Such as the hack
that silently turned a null class loader into the system class loader
for Class.forName().

>   This code is exactly the same for
> JDK 1.2+ and GCJ.  Only the Makefile is different, in that it builds a
> Kawa executable - i.e. a shared library.  There is also a script to
> compile Kawa applications to executables.
>
> Now I can certainly change Kawa's makefiles to match the currently
> approved and supported manner of creating native-compiled executables.
> But what is that way?

http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ
But that is tailored to traditional java programs that you want to
quickly "port" to gcj without changing your own code.

>   The problem is that compiled Java code needs
> to be able to do Class.forName(NAME) and search the classpath.  What
> is the approved way to do this?  If GCJ doesn't support this, then
> I'm confused - I'd except lots of Java code to break.

Yes :{ We talked a lot about this on irc (#gcc @ irc.oftc.net) today.
There are a couple of solutions possible to make this work again for
pre-compiled programs that don't use -findirect-dispatch and gij as
launcher. Some of them are not really safe so close to the release... It
seems solvable, but might require some more thinking to do in a way that
impacts as less (libgcj) code as possible.

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part