Re: [REVIVED: PATCH PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[Bryce McKinlay <bmckinlay@gmail.com>]

On Fri, Feb 5, 2010 at 10:26 PM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
>
>
>    Hi lists,
>
>  In this PR, ecj1 is failing (on Cygwin, presumably MinGW as well) owing to
> unintended fallout from building libgcj as two separate DLLs.
>
>  There are only static dependencies (i.e. unresolved symbols in the ecj.o
> object) for ecjx to pull in the main libgcj at linktime, so only that DLL gets
> loaded into memory at runtime.  But the class loader wants to load something
> from the subsidiary (-noncore) DLL, and it's not present in memory, so it
> fails.  (IIUC this is what the class definition data that is stored in .jcr
> sections and made available to the class loader through a a .ctor-like
> mechanism in the crtbegin code is all about.)
>
>  In this patch, I add an arbitrary undef to the link spec, against a fairly
> randomly chosen symbol (my only criterion was that the org.ietf.jgss namespace
> is probably fairly stable) from the -noncore part of the library.  This
> sufficed to build an ecjx that links against and hence loads both DLLs, and it
> doesn't throw the exception shown in the PR anymore.

> libjava/ChangeLog:
>
>        PR java/42811
>        * configure.ac (libgcj_spec_lgcj_override): Add undefined reference
>        to arbitrary symbol in noncore library.

Hi Dave

I'm not sure if this sounds like the right fix. Isn't it the point of
libgcj-noncore that applications which only want "core" classes can
link a smaller libgcj without having to distribute or load the
"noncore" classes? Doesn't adding a dependency from libgcj to
libgcj-noncore defeat this?

If ecj needs something from -noncore, shouldn't it be ecj that
explicitly links it?

>        * jvmti.cc (_Jv_GetJVMTIEnv): Fix use of uninitialised memory
>        exposed by the above change.

This part is fine.

Bryce