From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16646 invoked by alias); 15 Feb 2010 13:04:27 -0000 Received: (qmail 16625 invoked by uid 22791); 15 Feb 2010 13:04:26 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-fx0-f218.google.com (HELO mail-fx0-f218.google.com) (209.85.220.218) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Feb 2010 13:04:18 +0000 Received: by fxm10 with SMTP id 10so4868044fxm.29 for ; Mon, 15 Feb 2010 05:04:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.154.73 with SMTP id d9mr555722hbc.135.1266239054518; Mon, 15 Feb 2010 05:04:14 -0800 (PST) In-Reply-To: <4B78BA6D.5000603@gmail.com> References: <4B6C9B26.3010106@gmail.com> <4B6D0C67.5030500@gmail.com> <4B78BA6D.5000603@gmail.com> Date: Mon, 15 Feb 2010 13:04:00 -0000 Message-ID: <7230133d1002150504r23738e28if92303426c349661@mail.gmail.com> Subject: Re: [REVIVED: PATCH PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1 From: Bryce McKinlay To: Dave Korn Cc: Java Patches , GCC Patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2010-q1/txt/msg00034.txt.bz2 On Fri, Feb 5, 2010 at 10:26 PM, Dave Korn wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D42811 > > > 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 someth= ing > 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 .j= cr > 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 fair= ly > randomly chosen symbol (my only criterion was that the org.ietf.jgss name= space > 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, a= nd 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? > =A0 =A0 =A0 =A0* jvmti.cc (_Jv_GetJVMTIEnv): Fix use of uninitialised mem= ory > =A0 =A0 =A0 =A0exposed by the above change. This part is fine. Bryce