[ Reviving a thread from 20090506, as the first step toward raising this issue
again on the lists, and just in case anyone was interested in the follow-on ...
]
David Daney wrote:
> Ralf Wildenhues wrote:
>> Hello Dave,
>>
>> * Dave Korn wrote on Wed, May 06, 2009 at 06:09:05PM CEST:
> [...]
>>> 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?
>>
>> 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).
>>
>
> Unfortunately it may not be a simple task to find a suitably large set
> of packages that satisfy this 'directed non-cyclic graph' criterion.
Not simple, but not so hard as to be impossible either; as it turns out, the
internal structure of libgcj looks a lot like a turnip, with a bunch of skinny
branchy foliage waving around on top, a few shallow roots spreading under the
ground, and a big ball of hair in the middle holding it all together, which
makes it actually quite easy to manually find a partition.
There are a couple of regressions to solve first, but it appears that I've
more-or-less cracked it. Full details are written up here:
http://gcc.gnu.org/wiki/Internal_dependencies_of_libgcj
cheers,
DaveK
