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

[Dave Korn <dave.korn.cygwin@googlemail.com>]

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