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

[Dave Korn <dave.korn.cygwin@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

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.
	(libgcj_spec_lgcj_bc_override): Likewise.

  I'm taking this for a bootstrap-and-test cycle on i686-pc-cygwin.  Does it
seem like a reasonable approach?

    cheers,
      DaveK


[-- Attachment #2: pr42811.diff --]
[-- Type: text/x-c, Size: 1104 bytes --]

Index: libjava/configure.ac
===================================================================
--- libjava/configure.ac	(revision 156467)
+++ libjava/configure.ac	(working copy)
@@ -244,9 +244,13 @@ if test "$enable_libgcj_sublibs" = yes ; then
   # tag "_bc" onto the end of it when we use it to generate the
   # spec, but that's an ugly thing to do when there are multiple
   # words in the string and you're relying on the ordering to
-  # append the correct one.
-  libgcj_spec_lgcj_override="-lgcj-noncore -lgcj"
-  libgcj_spec_lgcj_bc_override="-lgcj-noncore -lgcj_bc"
+  # append the correct one.  Note that we add an arbitrary undef
+  # from libgcj-noncore to ensure the library is actually linked
+  # and loaded, as there aren't static dependencies to tell us
+  # which classes will be loaded at runtime, so we need to ensure
+  # that all the class data (.jcr sections) are present and initialised.
+  libgcj_spec_lgcj_override="-lgcj-noncore -u__ZN3org4ietf4jgss10GSSManagerC1Ev -lgcj"
+  libgcj_spec_lgcj_bc_override="-lgcj-noncore -u__ZN3org4ietf4jgss10GSSManagerC1Ev -lgcj_bc"
 fi