summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--libguile/DYNAMIC-LINKING91
1 files changed, 86 insertions, 5 deletions
diff --git a/libguile/DYNAMIC-LINKING b/libguile/DYNAMIC-LINKING
index f4f44cf73..78fb4e586 100644
--- a/libguile/DYNAMIC-LINKING
+++ b/libguile/DYNAMIC-LINKING
@@ -36,18 +36,26 @@ Here is my plan with indications of progress.
"dynl-dld.c", "dynl-dl.c" or "dynl-shl.c".
I have renamed the SCM names of the functions, because they didnn't
- fit very well into Guile, the semantics are the same:
+ fit very well into Guile, the semantics are mostly the same:
SCM name Guile name
- dynl:link dynamic-link
- dynl:call dynamic-call
- dynl:main-call dynamic-args-call
- dynl:unlink dynamic-unlink
+ dynl:link dynamic-link FILENAME
+ dynl:call dynamic-call SYMBOL DYNOBJ
+ dynl:main-call dynamic-args-call SYMBOL DYNOBJ STRING-LIST
+ dynl:unlink dynamic-unlink DYNOBJ
I plan to generalise dynamic-call and dynamic-args-call to work with
arbitrary arguments, so these names are likely to change.
+* There's now one new function
+
+ dynamic-func SYMB DYNOBJ
+
+ It determines the address of a function in a dynamic object. The
+ result of this function can be used with `dynamic-call' and
+ `dynamic-args-call' as the SYMBOL.
+
PROBLEMS:
Can tsort cope with blank lines? This situation arises when
@@ -60,6 +68,8 @@ Here is my plan with indications of progress.
libguile as a shared library on the systems that support it. Libtool
seems to be the right solution.
+* Libguile is now build using libtool and it works fine for me.
+
- see how to couple dynamic linking with the module system. Dynamic
objects should have a way to specify the module they want to add
@@ -71,10 +81,81 @@ Here is my plan with indications of progress.
current scm_top_level_lookup_closure and do all the module switching
from Scheme.
+* I now have modified scm_sysintern to use the lookup procedure when
+ there is one. This is a temporal hack while waiting for the module
+ system to be accessible from C.
+
- use gtcltk as a test case for the above, so that TCL/Tk capabilities
can be added to guile at runtime.
+* Works.
+
+ When you link libgtcltk into your application and initialize it with
+
+ scm_init_gtcl ();
+ scm_init_gtk ();
+
+ you get the old behaviour. If you initialize it with
+
+ scm_init_ice_9_gtcltk_module ();
+
+ the TCL/Tk functions are made available in a module called
+ #/ice-9/gtcltk.
+
+ When you don't link libgtcltk into your application but put it
+ somewhere in your %load-path, it will be linked dynamically upon the
+ first `:use-module #/ice-9/gtcltk'. Using the %load-path for this
+ is probably not very smart.
+
+ From boot-9:
+
+;;; Dynamic linking of modules
+
+;; Initializing a module that is written in C is a two step process.
+;; First the module's `module init' function is called. This function
+;; is expected to call `scm_register_module_xxx' to register the `real
+;; init' function. Later, when the module is referenced for the first
+;; time, this real init function is called in the right context. See
+;; gtcltk-lib/gtcltk-module.c for an example.
+;;
+;; The code for the module can be in a regular shared library (so that
+;; the `module init' function will be called when libguile is
+;; initialized). Or it can be dynamically linked.
+;;
+;; You can safely call `scm_register_module_xxx' before libguile
+;; itself is initialized. You could call it from an C++ constructor
+;; of a static object, for example.
+;;
+;; To make your Guile extension into a dynamic linkable module, follow
+;; these easy steps:
+;;
+;; - Find a name for your module, like #/ice-9/gtcltk
+;; - Write a function with a name like
+;;
+;; scm_init_ice_9_gtcltk_module
+;;
+;; This is your `module init' function. It should call
+;;
+;; scm_register_module_xxx ("ice-9 gtcltk", scm_init_gtcltk);
+;;
+;; "ice-9 gtcltk" is the C version of the module name. Slashes are
+;; replaced by spaces, the rest is untouched. `scm_init_gtcltk' is
+;; the real init function that executes the usual initilizations
+;; like making new smobs, etc.
+;;
+;; - Make a shared library with your code and a name like
+;;
+;; ice-9/libgtcltk.so
+;;
+;; and put it somewhere in %load-path.
+;;
+;; - Then you can simply write `:use-module #/ice-9/gtcltk' and it
+;; will be linked automatically.
+;;
+;; This is all very experimental.
+
+
- see how G-Wrap and libffi can work together and extend dyn:call to
functions taking arbitrary arguments. Something along the lines