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

[Marius Vollmer]

NIIBE Yutaka <address@hidden> writes:

> 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.)

Is this a good assumption?  I'd rather work from what libtool
specifies, or guarantees to work portably.  My main point is that I
have a bad feeling about stretching the shared library systems too
far, since the different systems are, well, different on the various
platforms.  Ideally, we should also take systems into account that
don't have dynamic linking at all.

Basically, I want to be really conservative here.

> 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.

Yes, good point.  I haven't thought of this previously.  But again, I
feel safer when we would do it the standard way (standard for C, not
for Perl, etc, since the shared libraries have been designed for C).

> 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?

Hmm, we have `:use-module' etc right now, but this doesn't cover
versioning information.  Versioning seems not to bee too important for
Scheme code, since it can adapt very flexibly at load-time, but it is
crucial for C.  So we need to add versioning, like Rob suggested.  We
can do this, of course, but right now, we don't have it.

So, for the time being, I'm very much in favor of not trying to do
clever or even advanced things.  Guile is flexible enough so that
people can build there own schemes for dynamically linking extensions
and we might eventually advertise a more advanced solution than now.

> IMO, if we stick current wey, it is very difficult to extend the
> system and maintain the consistency.

What problems can you see?

> 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).

In what way is it a problem that we have a lot of libraries in
/usr/lib?
 
> My idea is:
>     Don't include the version dependency information in the shared
>     objects, but offer it in another level (in module/interface system).

What do we gain by this?  I agree that the dependency system offered
by shared libraries might not be the best one, and we might be able to
do a better job.  But wouldn't it be better to put the advances into
libtool?

>     Don't pollute /usr/lib (or /usr/include) for Guile extensions.

The Unix/C model of libraries might be broken, but I'd say that we
only make it worse when we try to fight it.  The bla-config utilities
(like gnome-config, guile-config, etc), convenient as they might seem,
are already on the verge of doing too much, and being too clever.  For
example, on one box, I have libgtk in /usr/lib and libguile in ~/lib.
In a program that uses both, I get a linker line like

    ... -L/usr/lib -lgtk ... -L/home/mvo/lib -lguile ...

This breaks because there is also a (old) libguile in /usr/lib.

I'm all for improving the Unix way of managing software components,
but I think we need to do this by changing the build tools like the
compiler itself, if we want to do it right.  IMO.


Please don't let this stop you from devisiong and trying out a better
system anyway.  This should be possible without changing Guile itself.