From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2326 invoked by alias); 10 Dec 2009 14:32:08 -0000 Received: (qmail 2296 invoked by uid 48); 10 Dec 2009 14:32:07 -0000 Date: Thu, 10 Dec 2009 14:32:00 -0000 Message-ID: <20091210143207.2295.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin* In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "howarth at nitro dot med dot uc dot edu" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2009-q4/txt/msg00086.txt.bz2 ------- Comment #35 from howarth at nitro dot med dot uc dot edu 2009-12-10 14:32 ------- This might be a red herring but after what I observed for PR42333 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c29) I went back and looked at how the libjava libraries and executables are linked on darwin. They all end up with /usr/lib/libSystem.B.dylib being resolved before /sw/lib/gcc4.4/lib/libgcc_s.1.dylib. This is likely due to unnecessary link flags for -ldl, -lpthread, -lm, etc that link in symlinks of /usr/lib/libSystem.B.dylib. What we saw in PR42333 was that certain symbols in libgcc can be overridden by those in libSystem if libSystem is linked in first. I am going to try to hack a build of gcc trunk such that we end up with.... libgcj.10.dylib: /sw/lib/gcc4.4/lib/libgcj.10.dylib (compatibility version 11.0.0, current version 11.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /sw/lib/gcc4.4/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) instead of... libgcj.10.dylib: /sw/lib/gcc4.4/lib/libgcj.10.dylib (compatibility version 11.0.0, current version 11.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /sw/lib/gcc4.4/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) etc to see if this has any impact on the PR41991 on darwin. Note that I not making any suggestions of how we would fix this if the cause is libSystem occurring first in the linkage but rather trying to find the origin of the unwinder aborts on darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991