This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [JAVA,libtool] Big libjava is biiiig.
* 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.
> 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.
> > 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
I understand that one might need -L$(here)/.libs with non-libtool
linking, where without it, -lgcj will not be found. But it makes
no sense to me when libtool _is_ used for linking. And here, libtool
must be the only user, if only for the simple reason that passing
'libgcj.la' (as opposed to '-lgcj') to the compiler driver (rather than
to libtool) will cause an error.
> >> 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 ...
If this turns out to be a lot of work to even stabilize, we can still
decide to let GCC do its own stuff for a while and reintegrate later.
> > 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.
Oh, I was intending for a complete autotool update for the GCC tree,
but given the delay on the license exception thing for Autoconf, I'm
not sure how well that will align with GCC being in Stage 1 ...
Cheers,
Ralf