Re: [PATCH] Thread Plug-in Support #2

[Rob Browning]

NIIBE Yutaka <address@hidden> writes:

> In my opinion, libguilereadline and libguileqthreads are not shared
> libraries, but just (dynamically loaded) shared objects.  Well, what's
> the difference?

The difference is that if we put them in /usr/lib, which is where they
are currently, then there's a name conflict without versioning.  So
you can't have guile 1.4 and guile 1.6 installed at the same time if
the libqthreads for guile 1.4 isn't 100% compatible with the one for
guile 1.6.

> While library has multiple entry points for ABI, shared object
> normally has single entry point for initialization and single entry
> point for finalization (if any).  The nature of ABI is quite
> different.

Right, but you still have to track compatibility somehow.  In g-wrap I
have the "shared lib" publish a function that returns version
information.  Then you can check at runtime to make sure the library
you loaded satisfies your needs, but I haven't actually started using
this.  The goal was to make sure that an app that loads two different
g-wrapped C libraries is always using compatible versions of the
underlying g-wrap architecture, so you don't get in to a situation
where one library produces <Foo*> objects that aren't the same
internally as the other library's <Foo*> objects.  I don't claim that
I've got this quite right yet, though.  I'm sure the approach needs
some reconsideration and/or refinement.

> Thus, I think that Guile needs to have better distinction of library
> and shared objects.  Marius may have different opinion.

No problem, but we will need to do something differently soon.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930