From: Marius Vollmer <mvo@zagadka.ping.de>
Cc: guile-user@gnu.org
Subject: Re: updated $workbook/modules/modules-and-shared-libs.text
Date: 22 May 2002 14:28:38 +0200 [thread overview]
Message-ID: <87n0us74eh.fsf@zagadka.ping.de> (raw)
In-Reply-To: <E17AGzM-0001h2-00@giblet>
Thien-Thi Nguyen <ttn@giblet.glug.org> writes:
> i've added some comments.
me too. Woohoo, discussion via CVS...
The following is by mvo, w/ editorial comments by by others.
The latter can be identified by "[NAME: ....]".
_________________________________________________________________
Guile used to be able to automatically find and link a shared
library to satisfy requests for a module. For example, the module
`(foo bar)' could be implemented by placing a shared library named
"foo/libbar.so" (or with a different extension) in a directory on the
load path of Guile.
This has been found to be too tricky, and is no longer supported. The
shared libraries are now called "extensions". You should now write a
small Scheme file that calls `load-extension' to load the shared
library and initialize it explicitely.
[ttn: This decision to drop support applies to guile-1.6.x;
guile-1.4.x continues to support this.]
[mvo: However, it is not clear yet that there will be a 1.4.x series.]
Here is more about why "this has been found to be to tricky". It is
about the way it was done, not about why it can't possible at all.
While this support was still present, modules could be either
implemented by Scheme source files, or by shared libraries compiled
from C. These two forms are two very different things: one is
platform independent and installed somewhere in 'prefix', the other is
platform dependent and is installed in 'exec-prefix'. However, Guile
had no platform dependent locations in its default search path.
Moreover, the search algorithm required shared libraries that were to
be autoloaded as modules to reside not in the usual library
directories (like /usr/local/lib), but in Guile search path as
.../foo/libbar.so for example for module (foo bar). This will not
really work for shared libraries that are also to be used from C code.
Guile usually provides a C API for its features that are written in C.
This should be encouraged for extensions as well. However, the Unix
shared library does not deal well with shared libraries that don't
come from standard locations or are referenced by multiple names
(symlinks).
[ttn: Guile uses libtool and consequently libltdl, so it is possible
to use `lt_dlsetsearchpath' to alleviate (and actually bypass)
OS restrictions. A scheme binding for `lt_dlsetsearchpath' is
also possible. Thus, this argument against guile-1.4.x system
actually can be recast as an argument for providing access and
appropriate supporting protocol to `lt_dlsetsearchpath'.]
[mvo: Whatever additional tricks libltdl does, they do not apply to ld
or ld.so. Shared libraries are not only used at run-time (via
lt_dlopen, say), but also at link-time (by ld) and load-time (by
ld.so, or whatsitcalledonyourplatform). It might very well be
possible to design something that is more advanced than
'load-extension' and plays well with lt_dlopen, ld, and ld.so,
but limiting us to the very simple things that 'load-extension'
does now gives us (at least, me) good confidence that it will
work fairly portably.]
Additionally, module boundaries are not necessarily language
boundaries. That is, a module can be a mix of Scheme and C (and one
file might want to provide more than one module). Therefore, we need
a good way to load shared libraries independently from modules anyway.
[ttn: In dynl.c there are several good ways already. The guile-1.6.x
`load-extension' doesn't seem to be very much value-add over the
already provided and stable mechanisms. There is no spec for it,
including failure modes. There are plans to change its interface
incompatibly. Its registry is opaque (and redundant).]
[mvo: It is deliberate that 'load-extension' adds very little over
dynamic-link/dynamic-call. I don't know of any plans to change
its interface incompatibly. You can ignore the registry. It is
there for people who want to statically link extensions.]
Restricting module system operations and autoloading to Scheme code
only provided an immediate and significant simplification, without
much hassle to the user. The simplified setup should also be easier
to understand.
[ttn: The "without much hassle" is unfounded, unfortunately. The
guile-1.4.x system supports C++ encapsulation of a "module"
as a C++ object, and two-phase protocol for use: registration
before libguile is initialized, and then run-time loading as
described above. Registry manipulation is supported. None
of this is available w/ guile-1.6.x if configured w/ the
"--disable-deprecated" option. None of this is available
in HEAD at this time (2002-05-21).]
[mvo: Yes, "much hassle" is a subjective term. But there are no
complaints (besides yours) about it.]
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user
next prev parent reply other threads:[~2002-05-22 12:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-21 21:16 updated $workbook/modules/modules-and-shared-libs.text Thien-Thi Nguyen
[not found] ` <20020521173935.5f721206.dsmith@altustech.com>
2002-05-21 22:16 ` Thien-Thi Nguyen
2002-05-21 22:30 ` Bill Gribble
2002-05-21 23:31 ` Thien-Thi Nguyen
2002-05-22 1:52 ` Rob Browning
2002-05-22 2:11 ` Thien-Thi Nguyen
2002-05-22 4:23 ` Rob Browning
2002-05-22 7:40 ` Thien-Thi Nguyen
2002-05-22 12:28 ` Marius Vollmer [this message]
2002-05-22 19:29 ` Thien-Thi Nguyen
2002-05-22 20:09 ` conversation via CVS Joshua Judson Rosen
2002-05-22 20:48 ` Thien-Thi Nguyen
2002-05-22 23:37 ` Joshua Judson Rosen
2002-05-22 23:43 ` Thien-Thi Nguyen
2002-05-23 11:47 ` MJ Ray
2002-05-22 20:54 ` updated $workbook/modules/modules-and-shared-libs.text Marius Vollmer
2002-05-22 22:27 ` Thien-Thi Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87n0us74eh.fsf@zagadka.ping.de \
--to=mvo@zagadka.ping.de \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).