Re: [JAVA,libtool] Big libjava is biiiig.

[Andrew Haley <aph@redhat.com>]

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.