This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: [JAVA,libtool] Big libjava is biiiig.
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.