From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25338 invoked by alias); 11 May 2009 17:14:53 -0000 Received: (qmail 25319 invoked by uid 22791); 11 May 2009 17:14:51 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.157) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 May 2009 17:14:46 +0000 Received: by fg-out-1718.google.com with SMTP id l27so688953fgb.5 for ; Mon, 11 May 2009 10:14:43 -0700 (PDT) Received: by 10.86.1.18 with SMTP id 18mr6732881fga.19.1242062083101; Mon, 11 May 2009 10:14:43 -0700 (PDT) Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id l19sm4882604fgb.2.2009.05.11.10.14.38 (version=SSLv3 cipher=RC4-MD5); Mon, 11 May 2009 10:14:39 -0700 (PDT) Message-ID: <4A085FAA.6060507@gmail.com> Date: Mon, 11 May 2009 17:27:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ralf Wildenhues , Dave Korn , 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> In-Reply-To: <20090507214936.GB18769@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00265.txt.bz2 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. cheers, DaveK