From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23309 invoked by alias); 16 Aug 2004 08:37:04 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 23291 invoked by uid 48); 16 Aug 2004 08:37:03 -0000 Date: Mon, 16 Aug 2004 08:37:00 -0000 Message-ID: <20040816083703.23290.qmail@sourceware.org> From: "jari dot korva at iki dot fi" To: java-prs@gcc.gnu.org In-Reply-To: <20040806144324.16899.jari.korva@iki.fi> References: <20040806144324.16899.jari.korva@iki.fi> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug java/16899] Gcj does not produce working executables for big endian ARMs X-Bugzilla-Reason: CC X-SW-Source: 2004-q3/txt/msg00265.txt.bz2 List-Id: ------- Additional Comments From jari dot korva at iki dot fi 2004-08-16 08:36 ------- By chance, I found out that by commenting out a few lines from ClassLoader.getSystemClassLoader(), I'm able to produce working binaries for armv5b. I didn't include a patch because this does not seem look like a real solution: public static ClassLoader getSystemClassLoader() { // Check if we may return the system classloader // SecurityManager sm = System.getSecurityManager(); // if (sm != null) { Class c = VMSecurityManager.getClassContext()[1]; ClassLoader cl = c.getClassLoader(); // if (cl != null && cl != systemClassLoader) // sm.checkPermission(new RuntimePermission("getClassLoader")); } return systemClassLoader; } Does anyone who has more knowlegde about gcj internals have any idea what is the real reason behind this? I also confirmed that the bug still exists in gcj 3.4.1. -- What |Removed |Added ---------------------------------------------------------------------------- Version|3.4.0 |3.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16899