Re: Enhancement Request

[Glenn Chambers <gchamber at bright dot net>]

On Tuesday, December 31, 2002, at 03:30 AM, Tom Tromey wrote:

> I looked at this issue some more tonight.
>
> For the GC it probably makes more sense for Portable.NET to use the
> upstream version.  It has all the configure bits in it, and I know
> somebody has upgraded it to use autoconf 2.5x (something we still
> can't use in our tree).  I have a patch to disable installation of the
> headers which I'll check in soon
My problem with this strategy is that I find it hard to see how linking
two distinct versions of 'libgc' will be able to work.  Even assuming the
code issues work out, there's still the fact that there will be two gc'd
memory pools running in parallel, resulting in memory wastage.  There's
also the mildly interesting question of whether GC-A will scan GC-B's
pool looking for live pointers into GC-A's pool of objects.

> For libffi, I think it would make the most sense for somebody to do an
> independent release of the library.  Actually, it could use some
> install attention in general; for instance right now the installed
> fficonfig.h defines stuff without an `FFI_' prefix -- history has
> shown that this leads to problems.  Unfortunately fixing this probably
> means touching code all over the place.
Upon further review, it seems that unless libffi has a bunch of global
data structures (I haven't looked), that having two distinct 
implementations
in the same application is unlikely to cause major problems.  The issue
is the same as libgc - if Portable.NET links statically against libffi.1
and loads libgcj.so, which contains a libffi.2 (statically linked), then
what happens to any globals from libffi?  If they're distinct, then
things (should) work; if one overrides the other, then I'm doomed.

> Also we build libffi as a convenience library.  Will this cause
> problems for you?  If so, I don't know if there is a way around it in
> our tree, since we probably can't build it both ways at once.
Portable.NET currently links against a static libffi.a, so that shouldn't
be a problem.

> Anyway, once a small bug in the top-level Makefile is fixed, we'll
> still be installing libffi, warts and all.  I'm of two minds on this,
> but I for inertia carries the day.
>
> Tom
I'm not subscribed to gcc@gnu.org, but I follow it on the web archives,
so I saw your conversations on the subject with Nathaniel (sp?).

Thanks for the help.

Glenn Chambers
Toledo, OH