From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1028 invoked by alias); 11 May 2009 17:26:29 -0000 Received: (qmail 1011 invoked by uid 22791); 11 May 2009 17:26:28 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 May 2009 17:26:23 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n4BHQMRZ009196; Mon, 11 May 2009 13:26:22 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n4BHQGaf001195; Mon, 11 May 2009 13:26:17 -0400 Received: from zebedee.pink (vpn-14-75.rdu.redhat.com [10.11.14.75]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n4BHQEIY004360; Mon, 11 May 2009 13:26:15 -0400 Message-ID: <4A085FB6.7060002@redhat.com> Date: Mon, 11 May 2009 17:26:00 -0000 From: Andrew Haley User-Agent: Thunderbird 2.0.0.17 (X11/20081009) MIME-Version: 1.0 To: Dave Korn CC: Ralf Wildenhues , java@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: [JAVA,libtool] Big libjava is biiiig. References: <4A01B55C.6060700@gmail.com> <4A01B621.7020609@gmail.com> <20090506161419.GA19953@ins.uni-bonn.de> <4A01C401.4000104@gmail.com> <20090507214936.GB18769@gmx.de> <4A085FAA.6060507@gmail.com> In-Reply-To: <4A085FAA.6060507@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00038.txt.bz2 Dave Korn wrote: > Ralf Wildenhues wrote: >> * Dave Korn wrote on Wed, May 06, 2009 at 07:08:17PM CEST: >>> Ralf Wildenhues wrote: >>>> I don't yet see why you would need any kind of libtool hacking. >>> Because of this: >>> >>>> You also have to ensure that the sub libraries are self-contained, or at >>>> least their interdependencies form a directed non-cyclic graph (or you >>>> will need very ugly hacks on w32). >>> I fully expect there to be cyclic interdependencies, which I could resolve >>> by building import libs first with dlltool. I'm not sure yet whether to do >>> this in libtool, but it occurred to me as one possibility. >> If you could show the commands that would be needed without libtool, >> then it would be easier for me to understand how libtool could help. >> Of course, the more generally usable the approach, the better. > > Ok, so what I have is a big bunch of objects, that would normally be linked > together to make a single DLL, with all interdependencies resolved internally > and no undefined references: > > g++ -shared a1.o a2.o a3.o b1.o b2.o b3.o c1.o c2.o c3.o \ > -o cygexample.dll -Wl,--out-implb libexample.dll.a > > What I instead want to do is partition the objects into (for example) three > separate sublibraries: > > g++ -shared a1.o a2.o a3.o \ > -o cygexample-a.dll -Wl,--out-implb libexample-a.dll.a > g++ -shared b1.o b2.o b3.o \ > -o cygexample-b.dll -Wl,--out-implb libexample-b.dll.a > g++ -shared c1.o c2.o c3.o \ > -o cygexample-c.dll -Wl,--out-implb libexample-c.dll.a > > That won't work as-is because of the interdependencies; we can assume any of > the a/b/c objects may refer to any of the others. So we need to do: > > g++ -shared a1.o a2.o a3.o -lexample-b -lexample-c \ > -o cygexample-a.dll -Wl,--out-implb libexample-a.dll.a > g++ -shared b1.o b2.o b3.o -lexample-a -lexample-c \ > -o cygexample-b.dll -Wl,--out-implb libexample-b.dll.a > g++ -shared c1.o c2.o c3.o -lexample-a -lexample-b \ > -o cygexample-c.dll -Wl,--out-implb libexample-c.dll.a > > ... but as the import libs libexample-*.dll.a are generated as side-effects of > the link that builds the DLLs, they aren't available in time. So we have to > use dlltool first to generate import libs ahead of final-link time (without > attmepting to build a complete DLL): > > dlltool a1.o a2.o a3.o -D cygexample-a.dll -e libexample-a.dll.a > dlltool b1.o b2.o b3.o -D cygexample-b.dll -e libexample-b.dll.a > dlltool c1.o c2.o c3.o -D cygexample-c.dll -e libexample-c.dll.a > g++ -shared a1.o a2.o a3.o -lexample-b -lexample-c \ > -o cygexample-a.dll > g++ -shared b1.o b2.o b3.o -lexample-a -lexample-c \ > -o cygexample-b.dll > g++ -shared c1.o c2.o c3.o -lexample-a -lexample-b \ > -o cygexample-c.dll > >>> Another approach >>> would have been to do it in the Makefile, by first building the sub-DLLs all >>> linked against the monolithic libjava DLL, then rebuilding them all but this >>> time linking against their own import libs generated in the previous step; it >>> occurred to me that even this might need a little help from libtool. >> I agree that this sounds a bit awkward. > > True, but I'm not sure how well the libtool way-of-doing-things will adapt > to building in two stages. It might be simplest just to invoke dlltool from > the libjava makefile to get the import libs built first, and feed them as > ready-made inputs to bog-standard libtool invocation, do you think? I think I > might give that approach a try. Did you try my list of things to lift out? I don't think there will be any interdependencies; the only problem might be that the reduction is not enough. Andrew.