This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [JAVA,libtool] Big libjava is biiiig.
Ralf Wildenhues wrote:
> Hello Dave,
Hiya Ralf,
> 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. 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 also don't see why the GCC tree *ever* uses -L$(something)/.libs in
> directories where libtool is used. Just specify in-tree library
> dependencies as 'libgcj.la' and automake and libtool will do The Right
> Thing. You adding an explicit -L.libs can only lead to installed .la
> files retaining paths to build tree locations.
Right, I'll try it; I have no idea why it's like that, I just cut and pasted
existing examples without fully understanding. The comment on the bit I cut
and pasted reads:
## We don't explicitly link in the libraries we need; libgcj.la brings
## in all dependencies. We need the -L so that gcj can find libgcj
## with `-lgcj', but it must come first, otherwise the -L flags
## brought in from libgcj.la would cause the install directories to be
## searched before the build-tree ones, and we'd get errors because of
## different libraries with the same SONAME from picky linkers such as
## Solaris'. FIXME: should be _libs on some systems.
jv_convert_LDADD = -L$(here)/.libs libgcj.la
>> 1) Would this be a reasonable approach, specifically i) in adding a configure
>> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
>> construct to crudely subdivide the libraries like this?
>
> You are aware of the fact that it is part of the ABI in which of the
> linked DLLs a given symbol was found, and any shuffling of that later
> will break that ABI?
Yep. I guess I didn't think that the top-level hierarchy might be
rearranged, or objects moved from one part of the sub-tree to another; is that
likely?
>> 2) Given that there's a bit of a logjam upstream, and not likely to be
>> another libtool release betwen now and the end of stage1,
>
> What makes you think so? There is a backlog of some patches, but that
> doesn't mean
> - important patches won't go in,
Oh, great. I didn't want to /rely/ on being able to draw on your time when
you've already got a lot to deal with, but in combination with this ...
> - GCC can't update to a newer unreleased Libtool version; it has done
> this several times, and it does not require the GCC developers to
> upgrade their build tools.
(which I didn't know this was standard practice) that makes it seem far more
possible to do things the right way round.
> I don't see a reason for that in your message. Do you have other
> reasons for suggesting this?
Nope, I was only planning ahead against the contingency of it either not
being practicable or convenient upstream, or there being subtle problems that
transpire with doing an entire libtool update/merge.
cheers,
DaveK