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

[NIIBE Yutaka]

Hi, 

Rob Browning wrote:
 >   (1) I think last time I talked about this (on guile-devel I
[...]
 >       problem, at least with Debian since there we already have
 >       libguilereadline.9.0.0 and libguileqthreads.9.0.0.

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

The library is referenced and linked by program (or other libraries),
at compile-time and link-time.  While shared object is _not_
referenced and linked at comile time at all, it's used on demand at
runtime.

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.

For shared objects (of Guile), even if the ABI were same, the behavior
(in result) could be very different.  For example, it might be same
ABI (same entry) in C language level, but in Scheme level it might
exports many other symbols.

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

(Having embedded (dumped, unexcedd) binary which works as if it has
dynamic loading feature (but not in fact), is another issue...)

Besides, 

 >       We should proabably at least make sure our strategy is
 >       compatible with libtool's (and from looking at RELEASE, I
 >       suspect it is, though our method isn't as sophisticated).

I agree this.
--