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.
