From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10751 invoked by alias); 10 Dec 2008 13:30:13 -0000 Received: (qmail 10729 invoked by uid 48); 10 Dec 2008 13:30:12 -0000 Date: Wed, 10 Dec 2008 13:30:00 -0000 Message-ID: <20081210133012.10728.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" 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: 2008-q4/txt/msg00111.txt.bz2 ------- Comment #17 from jakub at gcc dot gnu dot org 2008-12-10 13:30 ------- For #c12, those weren't present in 4.3 libgcj_bc.so, but I don't see why it matters. 4.3 linked ecj1 doesn't need any of those symbols. The reason why it has DT_NEEDED libgcj.so.9 is IMHO that libgcj.la was in ecjx's LDADD, so libtool linked it with -lgcj (and as -Wl,--as-needed -lgcj -Wl,--no-as-needed wasn't used, it was added to DT_NEEDED unconditionally). The fix really is not to have libgcj.la in LDADD for dynamically linked ecj1. I'm just not sure about !ENABLE_SHARED build if USE_LIBGCJ_BC is true, maybe libgcj.la is needed in that case (not sure if libgcj_bc.la has libgcj.la as a dependency in that case). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38396