From dev-return-39406-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Wed Jun 02 10:13:24 2010 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 82304 invoked from network); 2 Jun 2010 10:13:23 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Jun 2010 10:13:23 -0000 Received: (qmail 39374 invoked by uid 500); 2 Jun 2010 10:13:23 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 39186 invoked by uid 500); 2 Jun 2010 10:13:21 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 39177 invoked by uid 99); 2 Jun 2010 10:13:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jun 2010 10:13:20 +0000 X-ASF-Spam-Status: No, hits=-2.1 required=10.0 tests=AWL,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 195.212.17.164 is neither permitted nor denied by domain of mark.hindess@googlemail.com) Received: from [195.212.17.164] (HELO mtagate4.de.ibm.com) (195.212.17.164) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jun 2010 10:13:11 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.1/8.13.1) with ESMTP id o52ACoTl008916 for ; Wed, 2 Jun 2010 10:12:50 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o52ACovJ1212448 for ; Wed, 2 Jun 2010 12:12:50 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o52ACo4S026152 for ; Wed, 2 Jun 2010 12:12:50 +0200 Received: from anaheim.local (dhcp-9-20-183-162.hursley.ibm.com [9.20.183.162]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o52ACnpm026145 for ; Wed, 2 Jun 2010 12:12:50 +0200 Message-Id: <201006021012.o52ACnpm026145@d12av01.megacenter.de.ibm.com> X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-18) with nmh-1.3 From: "Mark Hindess" To: "Apache Harmony Dev List" Subject: [classlib] [build] Unnecessary linking Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jun 2010 11:12:49 +0100 If you are following the commits, you might have noticed that I am trying to fix some of the unnecessary linking in our builds. Most recently I've been looking at the linking of the static library hypool. We link against this static library in almost all of the build files in classlib but only hyzip (both versions) and hythr actually use it. However, if I remove the unnecessary references to hypool.{a,lib} from the build then some instrument tests fail. Running the failing test with ld debug like this: cd target/hdk/build/test/instrument LD_DEBUG_OUTPUT=ld.log LD_DEBUG=all \ ../../../jdk/jre/bin/java \ -cp ../junit.jar:../hamcrest-library.jar:instrument_tests.jar \ org.junit.runner.JUnitCore \ org.apache.harmony.tests.java.lang.instrument.HelloWorldTest reveals the problem[0]: target/hdk/jdk/jre/bin/libhyinstrument.so: error: symbol lookup error: undefined symbol: pool_removeElement (fatal) The problem is that while instrument doesn't use hypool. It does statically link hyzip which does use hypool but does not include it. Obviously I could just link hyinstrument with hypool again but fixing indirect dependencies this way seems kind of ugly. Fixing it on windows is straightforward as adding a .lib to a .lib does the right thing. But on linux you can't just include hypool.a in hyzip.a because it just creates a nested archive so you have to un/pack the members. I'm just running a few more tests before I check in the changes but I thought I'd mention it here since the reason for the changes wont be entirely obvious from the diff and because the LD_DEBUG trick is quite useful for debugging these kind of problems. Regards, Mark. [0] Find the correct log for the child process, jump to the end and search back for "fatal".