X-Git-Url: http://git.chise.org/gitweb/?a=blobdiff_plain;f=man%2Femodules.texi;h=93edb70df45d3b5b2a7373a58d66c0cdb7945c96;hb=818f224de6694aa92bf9ba77b52c8c8d0dd24999;hp=b1b250acd4a783a9f05e5b79623630b9474a7475;hpb=c5e615c17f89a5d09fedffc7a387162d12e1b8a6;p=chise%2Fxemacs-chise.git.1

diff --git a/man/emodules.texi b/man/emodules.texi
index b1b250a..93edb70 100644
--- a/man/emodules.texi
+++ b/man/emodules.texi
@@ -478,6 +478,20 @@ will be unloaded.  This means that if any child modules fail to load,
 then their parents will also fail to load.  This does not include
 previous successful calls to @code{emodules_load} at the top level.
 
+@strong{Warning:} Modules are @emph{not} loaded with the
+@code{RTLD_GLOBAL} flag.  The practical upshot is that individual
+modules do not have access to each other's C symbols.  One module cannot
+make a C function call to a function defined in another module, nor can
+it read or set a C variable in another module.  All interaction between
+modules must, therefore, take place at the Lisp level.  This is by
+design.  Other projects have attempted to use @code{RTLD_GLOBAL}, only
+to find that spurious symbol name clashes were the result.  Helper
+functions often have simple names, increasing the probability of such a
+clash.  If you really need to share symbols between modules, create a
+shared library containing those symbols, and link your modules with
+that library.  Otherwise, interactions between modules must take place
+via Lisp function calls and Lisp variables accesses.
+
 @node Using ellcc, Defining Functions, Anatomy of a Module, Top
 @chapter Using @code{ellcc}
 @cindex @code{ellcc}
@@ -653,17 +667,17 @@ The above @file{Makefile} is, in fact, complete, and would compile the
 sample module, and optionally install it.  The @code{--mod-location}
 argument to @code{ellcc} will produce, on the standard output, the base
 location of the @value{emacs} module directory.  Each sub-directory of that
-directory is automatically searched for for modules when they are loaded
-with @code{load-module}.  An alternative location would be
-@file{/usr/local/lib/xemacs/site-modules}.  That path can change
-depending on the options the person who compiled @value{emacs} chose, so you
-can always determine the correct site location using the
-@code{--mod-site-location} option.  This directory is treated the same
-way as the main module directory.  Each sub-directory within it is
-searched for a given module when the user attempts to load it.  The
-valid extensions that the loader attempts to use are @file{.so},
-@file{.ell} and @file{.dll}.  You can use any of these extensions,
-although @file{.ell} is the preferred extension.
+directory is automatically searched for modules when they are loaded with
+@code{load-module}.  An alternative location would be
+@file{/usr/local/lib/xemacs/site-modules}.  That path can change depending
+on the options the person who compiled @value{emacs} chose, so you can
+always determine the correct site location using the
+@code{--mod-site-location} option.  This directory is treated the same way
+as the main module directory.  Each sub-directory within it is searched for
+a given module when the user attempts to load it.  The valid extensions that
+the loader attempts to use are @file{.so}, @file{.ell} and @file{.dll}.  You
+can use any of these extensions, although @file{.ell} is the preferred
+extension.
 
 @node Link Mode, Other ellcc options, Initialization Mode, Using ellcc
 @section Link Mode