Often you will want to extend Guile by linking it with some existing
system library. For example, linking Guile with a curses
or
termcap
library would be useful if you want to implement a
full-screen user interface for a Guile application. However, if you
were to link Guile with these libraries at compile time, it would bloat
the interpreter considerably, affecting everyone on the system even if
the new libraries are useful only to you. Also, every time a new
library is installed, you would have to reconfigure, recompile and
relink Guile merely in order to provide a new interface.
Many Unix systems permit you to get around this problem by using dynamic loading. When a new library is linked, it can be made a dynamic library by passing certain switches to the linker. A dynamic library does not need to be linked with an executable image at link time; instead, the executable may choose to load it dynamically at run time. This is a powerful concept that permits an executable to link itself with almost any library without reconfiguration, if it has been written properly.
Guile's dynamic linking functions make it relatively easy to write a module that incorporates code from third-party object code libraries.
#t
if obj is a dynamic library handle, or #f
otherwise.
dynamic-func
. Otherwise, it should
be a function handle returned by a previous call to dynamic-func
.
The return value is unspecified.
dynamic-call
,
proc should be either a function handle or a string, in which case
it is first fetched from lib with dynamic-func
.
proc is assumed to return an integer, which is used as the return
value from dynamic-args-call
.
use-modules
, for instance), and whose cdr is the function handle
for that module's initializer function.
[FIXME: provide a brief example here of writing the C hooks for an object code module, and using dynamic-link and dynamic-call to load the module.]
Go to the first, previous, next, last section, table of contents.