*** empty log message ***

diff --git a/libguile/DYNAMIC-LINKING b/libguile/DYNAMIC-LINKING
index cb71343..f4f44cf 100644 (file)
--- a/libguile/DYNAMIC-LINKING
+++ b/libguile/DYNAMIC-LINKING
@@ -50,17 +50,15 @@ Here is my plan with indications of progress.
 
   PROBLEMS:
 
-  When including dynlink support in libguile you need to link your
-  applications with additional libraries (-ldl or -ldld). How do you
-  communicate this to "guile" and "gh_test" for example? Some PLUGIN
-  magic?
+  Can tsort cope with blank lines? This situation arises when
+  configure substitutes nothing for @xtra_PLUGIN_guile_libs@.
 
   You may need to link your application in a special way to make
   dynamic linking work. For example, on Linux and a statically linked
   libguile.a, you need -rdynamic to make the libguile symbols
   available for dynamic linking. The solution is probably to build
-  libguile as a shared library on the systems that support it. Does
-  libtool help here? Where can I find it?
+  libguile as a shared library on the systems that support it. Libtool
+  seems to be the right solution.
 
 
 - see how to couple dynamic linking with the module system. Dynamic
@@ -83,6 +81,8 @@ Here is my plan with indications of progress.
     (define XOpenDisplay (make-foreign-function X11-lib 'XOpenDisplay
                                                .. whatever args ..))
 
+* I have received Guile libffi glue code from Anthony Green but I have
+  yet to try it out.
 
 I have no ideas how to support the development of packages for Guile
 that can be dynamically linked into a running application.  Maybe
@@ -93,3 +93,15 @@ packages have already installed Guile. So we might able to use Scheme
 to describe and handle the build process. I would like that much more
 than the arcane shell based implementations of autoconf, automake,
 etc.
+
+One more random thought about packages: I think it would be an
+advantage if the configuration informations are not contained in a
+bunch of files (like the PLUGIN stuff, or like tclConfig.sh) that have
+to be found and analyzed, but rather can be accessed via a small
+program that can be assumed to be in the PATH. That program (probably
+a shell script, but not necessarily) can be queried about several
+interesting things like prefix and exec_prefix of libguile or told to
+do some tasks like installing a new module (and constructing a new
+guile executable if that is necessary). It might even be used for such
+generic things as uninstalling Guile (or downloading, configuring,
+building and installing the latest version of Guile...)