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

[NIIBE Yutaka]

Marius Vollmer wrote:
 > I would like to view Guile extensions that are linked at run-time
 > foremost as normal shared libraries, not as plugins.  These extensions
 > shuld not only be useful to be linked in and add some Scheme bindings,
 > they should also be useful to be linked explicitely with other
 > extensions or applications.

Umm... I don't understand your point here.  I think that there's
disagreement/mis-understanding of some assumptions among us.  Let me
explain a bit.  (From here, I assume ELF dynamic loading, to be
concrete.)

I agree that it should be possible to write other extensions (or
applications) which uses the C bindings of a extension.  But the
extension does not require to be _linked_ to a extension at compile
time. <------- Important point.

Shared objects can have unresolved symbols, which resolved after
dynamic linking.

When we link the shared library at compile time, the dependency
information is placed at the DT_NEEDED entry.  The information in
DT_NEEDED entry is just a way of describing the dependency.  Dynamic
linker uses that entry, but if Guile system could handle the
dependency in another way, it is certainly no problem not using
DT_NEEDED entry.

Well, let think by an example.  We have extension A, and build
another extension B and a application C which depend on A.

Let's consider two cases: 
  (1) B or C are linked to extension A at compile time
  (2) B or C are *not* linked to extension A at compile time

The differences in the resulted shared objects are:
  (1) DT_NEEDED has dependency information to A 
      No unresolved symbols
  (1) DT_NEEDED has no dependency information to A 
      Has unresolved symbols

The differnece of requirement of system is:
  (1) A is loaded by dynamic-linker (ld.so) automatically
  (2) Guile system should aware of the dependency (in some way)

And, I assume that Guile system should aware of the dependency to
handle interface match or versioning.  We definitely needs
the module/interface/extension handling system in Guile, don't we?

 > Maybe it can be made to work, and people are free to do it, but I
 > wouldn't want to recommend it as the standard way of installing Guile
 > extensions.

It works well.  It's not just working well but it is the standard way
of doing things for extention, see Perl or Python for examples.

IMO, if we stick current wey, it is very difficult to extend the
system and maintain the consistency.  It results bunch of
libguileXXX.so(s) under /usr/lib, and if we release new libguile.so,
users will see another set of libguileXXX.so(s).

My idea is:
    Don't include the version dependency information in the shared
    objects, but offer it in another level (in module/interface system).
    Don't pollute /usr/lib (or /usr/include) for Guile extensions.
--