guile-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Guile-commits] branch excise-ltdl updated: Further WIP, to squish later


From: Andy Wingo
Subject: [Guile-commits] branch excise-ltdl updated: Further WIP, to squish laters
Date: Sun, 24 Jan 2021 15:47:09 -0500

This is an automated email from the git hooks/post-receive script.

wingo pushed a commit to branch excise-ltdl
in repository guile.

The following commit(s) were added to refs/heads/excise-ltdl by this push:
     new fca4677  Further WIP, to squish laters
fca4677 is described below

commit fca467743d7fc25fccbfaddfe7b7cced02b9ca33
Author: Andy Wingo <wingo@pobox.com>
AuthorDate: Sun Jan 24 21:46:56 2021 +0100

    Further WIP, to squish laters
---
 doc/ref/api-foreign.texi | 496 ++++++++++++++++++++++++-----------------------
 doc/ref/guile.texi       |   2 +-
 2 files changed, 254 insertions(+), 244 deletions(-)

diff --git a/doc/ref/api-foreign.texi b/doc/ref/api-foreign.texi
index 4679c56..1782d40 100644
--- a/doc/ref/api-foreign.texi
+++ b/doc/ref/api-foreign.texi
@@ -9,182 +9,206 @@
 @cindex foreign function interface
 @cindex ffi
 
-The more one hacks in Scheme, the more one realizes that there are
-actually two computational worlds: one which is warm and alive, that
-land of parentheses, and one cold and dead, the land of C and its ilk.
-
-But yet we as programmers live in both worlds, and Guile itself is half
-implemented in C. So it is that Guile's living half pays respect to its
-dead counterpart, via a spectrum of interfaces to C ranging from dynamic
-loading of Scheme primitives to dynamic binding of stock C library
-procedures.
+Sometimes you need to use libraries written in C or Rust or some other
+non-Scheme language.  More rarely, you might need to write some C to
+extend Guile.  This section describes how to load these ``foreign
+libraries'', look up data and functions inside them, and so on.
 
 @menu
-* Foreign Libraries::           Dynamically linking to libraries.
-* Foreign Functions::           Simple calls to C procedures.
-* C Extensions::                Extending Guile in C with loadable modules.
-* Modules and Extensions::      Loading C extensions into modules.
-* Foreign Pointers::            Accessing global variables.
-* Dynamic FFI::                 Calling arbitrary C functions.
+* Foreign Libraries::              Dynamically linking to libraries.
+* C Extensions::                   Extending Guile in C with loadable modules.
+* Modules and Extensions::         Loading C extensions into modules.
+* Foreign Pointers::               Accessing global variables.
+* Foreign Types::                  Expressing C types in Scheme.
+* Foreign Functions::              Simple calls to C procedures.
+* Foreign Variables::              Pointers to C symbols.
+* Void Pointers and Byte Access::  Pointers into the ether.
+* Foreign Structs::                Packing and unpacking structs.
+* More Foreign Functions::         Advanced examples.
 @end menu
 
 
 @node Foreign Libraries
 @subsection Foreign Libraries
 
-Most modern Unices have something called @dfn{shared libraries}.  This
-ordinarily means that they have the capability to share the executable
-image of a library between several running programs to save memory and
-disk space.  But generally, shared libraries give a lot of additional
-flexibility compared to the traditional static libraries.  In fact,
-calling them `dynamic' libraries is as correct as calling them `shared'.
-
-Shared libraries really give you a lot of flexibility in addition to the
-memory and disk space savings.  When you link a program against a shared
-library, that library is not closely incorporated into the final
-executable.  Instead, the executable of your program only contains
-enough information to find the needed shared libraries when the program
-is actually run.  Only then, when the program is starting, is the final
-step of the linking process performed.  This means that you need not
-recompile all programs when you install a new, only slightly modified
-version of a shared library.  The programs will pick up the changes
-automatically the next time they are run.
-
-Now, when all the necessary machinery is there to perform part of the
-linking at run-time, why not take the next step and allow the programmer
-to explicitly take advantage of it from within their program?  Of course,
-many operating systems that support shared libraries do just that, and
-chances are that Guile will allow you to access this feature from within
-your Scheme programs.  As you might have guessed already, this feature
-is called @dfn{dynamic linking}.@footnote{Some people also refer to the
-final linking stage at program startup as `dynamic linking', so if you
-want to make yourself perfectly clear, it is probably best to use the
-more technical term @dfn{dlopening}, as suggested by Gordon Matzigkeit
-in his libtool documentation.}
-
-We titled this section ``foreign libraries'' because although the name
-``foreign'' doesn't leak into the API, the world of C really is foreign
-to Scheme -- and that estrangement extends to components of foreign
-libraries as well, as we see in future sections.
-
-@deffn {Scheme Procedure} dynamic-link [library]
-@deffnx {C Function} scm_dynamic_link (library)
-Find the shared library denoted by @var{library} (a string) and link it
-into the running Guile application.  When everything works out, return a
-Scheme object suitable for representing the linked object file.
-Otherwise an error is thrown.  How object files are searched is system
-dependent.
-
-Guile first tries to load @var{library} as the absolute file name of a shared
-library.  If that fails, it then falls back to interpret
-@var{library} as just the name of some shared library that will be
-searched for in the places where shared libraries usually reside, such
-as @file{/usr/lib} and @file{/usr/local/lib}.
-
-@var{library} should not contain an extension such as @code{.so}, unless
-@var{library} represents the absolute file name to the shared library.  The
-correct file name extension for the host operating system is provided
-automatically.
-
-When @var{library} is omitted, a @dfn{global symbol handle} is returned.  This
-handle provides access to the symbols available to the program at run-time,
-including those exported by the program itself and the shared libraries already
-loaded.
-
-Note that on hosts that use dynamic-link libraries (DLLs), the global
-symbol handle may not be able to provide access to symbols from
-recursively-loaded DLLs.  Only exported symbols from those DLLs directly
-loaded by the program may be available.
-@end deffn
+Just as Guile can load up Scheme libraries at run-time, Guile can also
+load some system libraries written in C or other low-level languages.
+We refer to these as dynamically-loadable modules as @dfn{foreign
+libraries}, to distinguish them from native libraries written in Scheme
+or other languages implemented by Guile.
+@cindex foreign libraries
+@cindex libraries, foreign
+
+Foreign libraries usually come in two forms.  Some foreign libraries are
+part of the operating system, such as the compression library
+@code{libz}.  These shared libraries are built in such a way that many
+programs can use their functionality without duplicating their code.
+When a program written in C is built, it can declare that it uses a
+specific set of shared libraries.
+@cindex shared libraries
+@cindex libraries, shared
+When the program is run, the operating system takes care of locating and
+loading the shared libraries.
+
+The operating system components that can dynamically load and link
+shared libraries when a program is run are also available
+programmatically during a program's execution.  This is the interface
+that's most useful for Guile, and this is what we mean in Guile when we
+refer to @dfn{dynamic linking}.  Dynamic linking at run-time is
+sometimes called @dfn{dlopening}, to distinguish it from the dynamic
+linking that happens at program start-up.
+@cindex dynamic linking
+@cindex dlopening
+
+The other kind of foreign library is sometimes known as a module,
+plug-in, bundle, or an extension.  These foreign libraries aren't meant
+to be linked to by C programs, but rather only to be dynamically loaded
+at run-time -- they extend some main program with functionality, but
+don't stand on their own.  Sometimes a Guile library will implement some
+of its functionality in a loadable module.
+
+In either case, the interface on the Guile side is the same.  You load
+the interface using @code{load-foreign-library}.  The resulting foreign
+library object implements a simple lookup interface whereby the user can
+get addresses of data or code exported by the library.  There is no
+facility to inspect foreign libraries; you have to know what's in there
+already before you look.
+
+Routines for loading foreign libraries and accessing their contents are
+implemented in the @code{(system foreign-library)} module.
 
-@deffn {Scheme Procedure} dynamic-object? obj
-@deffnx {C Function} scm_dynamic_object_p (obj)
-Return @code{#t} if @var{obj} is a dynamic library handle, or @code{#f}
-otherwise.
-@end deffn
+@example
+(use-modules (system foreign-library))
+@end example
 
-@deffn {Scheme Procedure} dynamic-unlink dobj
-@deffnx {C Function} scm_dynamic_unlink (dobj)
-Unlink the indicated object file from the application.  The
-argument @var{dobj} must have been obtained by a call to
-@code{dynamic-link}.  After @code{dynamic-unlink} has been
-called on @var{dobj}, its content is no longer accessible.
+@deffn {Scheme Procedure} load-foreign-library [library] @
+       [#:extensions=system-library-extensions] @
+       [#:search-ltdl-library-path?=#t] @
+       [#:search-path=search-path] @
+       [#:search-system-paths?=#t]
+Find the shared library denoted by @var{library} (a string or @code{#f})
+and link it into the running Guile application.  When everything works
+out, return a Scheme object suitable for representing the linked object
+file.  Otherwise an error is thrown.
+
+If @var{library} argument is omitted, it defaults to @code{#f}.  If
+@code{library} is false, the resulting foreign library gives access to
+all symbols available for dynamic linking in the main binary.
+
+It is not necessary to include any extension such as @code{.so} in
+@var{library}.  For each system, Guile has a default set of extensions
+that it will try.  On GNU systems, the default extension set is just
+@code{.so}; on Windows, just @code{.dll}; and on Darwin (Mac OS), it is
+@code{.bundle}, @code{.so}, and @code{.dylib}.  Pass @code{#:extensions
+@var{extensions}} to override the default extensions list.  If
+@var{library} contains one of the extensions, no extensions are tried,
+so it is possible to specify the extension if you know exactly what file
+to load.
+
+Unless @var{library} denotes an absolute file name or otherwise contains
+a directory separator (@code{/}, and also @code{\} on Windows), Guile
+will search for the library in the directories listed in
+@var{search-paths}.  The default search path has three components, which
+can all be overriden by colon-delimited (semicolon on Windows)
+environment variables:
+
+@table @env
+@item GUILE_EXTENSIONS_PATH
+This is the main environment variable for users to add directories
+containing Guile extensions.  The default value has no entries.
+@item LTDL_LIBRARY_PATH
+To implement foreign library loading, before Guile 3.0.6 Guile used
+@code{libltdl}, the dynamic library loader provided by libtool.  This
+loader used @env{LTDL_LIBRARY_PATH}, and for backwards compatibility we
+still support that path.
+
+However, @code{libltdl} would not only open @code{.so} (or @code{.dll}
+and so on) files, but also the @code{.la} files created by libtool.  In
+installed libraries -- libraries that are in the target directories of
+@code{make install} -- @code{.la} files are never needed, to the extent
+that most GNU/Linux distributions remove them entirely.  It is
+sufficient to just load the @code{.so} (or @code{.dll} and so on) files,
+which are always located in the same directory as the @code{.la} files.
+
+But for uninstalled dynamic libraries, like those in a build tree, the
+situation is a bit of a mess.  If you have a project that uses libtool
+to build libraries -- which is the case for Guile, and for most projects
+using autotools -- and you build @file{foo.so} in directory @file{D},
+libtool will put @file{foo.la} in @file{D}, but @file{foo.so} gets put
+into @file{D/.libs}.
+
+Users were mostly oblivious to this situation, as @code{libltdl} had
+special logic to be able to read the @code{.la} file to know where to
+find the @code{.so}, even from an uninstalled build tree, preventing the
+existence of @file{.libs} from leaking out to the user.
+
+We don't use libltdl now, essentially for flexibility and
+error-reporting reasons.  But, to keep this old use-case working, if
+@var{search-ltdl-library-path?} is true, we add each entry of
+@code{LTDL_LIBRARY_PATH} to the default extensions load path,
+additionally adding the @file{.libs} subdirextories for each entry, in
+case there are @file{.so} files there instead of alongside the
+@file{.la} files.
+@item GUILE_SYSTEM_EXTENSIONS_PATH
+The last path in Guile's search path belongs to Guile itself, and
+defaults to the libdir and the extensiondir, in that order.  For
+example, if you install to @file{/opt/guile}, these would probably be
+@file{/opt/guile/lib} and
+@code{/opt/guile/lib/guile/@value{EFFECTIVE-VERSION}/extensions},
+respectively.  @xref{Parallel Installations}, for more details on
+@code{extensionsdir}.
+@end table
+
+Finally, if no library is found in the search path, and if @var{library}
+is not absolute and does not include directory separators, and if
+@var{search-system-paths?} is true, the operating system may have its
+own logic for where to locate @var{library}.  For example, on GNU, there
+will be a default set of paths (often @file{/usr/lib} and @file{/lib},
+though it depends on the system), and the @code{LD_LIBRARY_PATH}
+environment variable can add additional paths.  Other operating systems
+have other conventions.
+
+Falling back to the operating system for search is usually not a great
+thing; it is a recipe for making programs that work on one machine but
+not on others.  Still, when wrapping system libraries, it can be the
+only way to get things working at all.
 @end deffn
 
-@smallexample
-(define libgl-obj (dynamic-link "libGL"))
-libgl-obj
-@result{} #<dynamic-object "libGL">
-(dynamic-unlink libGL-obj)
-libGL-obj
-@result{} #<dynamic-object "libGL" (unlinked)>
-@end smallexample
-
-As you can see, after calling @code{dynamic-unlink} on a dynamically
-linked library, it is marked as @samp{(unlinked)} and you are no longer
-able to use it with @code{dynamic-call}, etc.  Whether the library is
-really removed from you program is system-dependent and will generally
-not happen when some other parts of your program still use it.
-
-When dynamic linking is disabled or not supported on your system,
-the above functions throw errors, but they are still available.
-
-
-@node Foreign Functions
-@subsection Foreign Functions
+The environment variables mentioned above are parsed when the
+foreign-library module is first loaded and bound to parameters.  Null
+path components, for example the three components of
+@env{GUILE_SYSTEM_EXTENSIONS_PATH="::"}, are ignored.
+
+@deffn {Scheme Parameter} guile-extensions-path
+@deffnx {Scheme Parameter} ltdl-library-path
+@deffnx {Scheme Parameter} guile-system-extensions-path
+Parameters initially bound to @env{GUILE_EXTENSIONS_PATH},
+@env{LTDL_LIBRARY_PATH}, and @env{GUILE_SYSTEM_EXTENSIONS_PATH},
+respectively.  @xref{Parameters}.  The current values of these
+parameters are used when building the search path when
+@code{load-foreign-library} is called, unless the caller explicitly
+passes a @code{#:search-path} argument.
+@end deffn
 
-The most natural thing to do with a dynamic library is to grovel around
-in it for a function pointer: a @dfn{foreign function}.
-@code{dynamic-func} exists for that purpose.
+@deffn {Scheme Procedure} foreign-library? obj
+Return @code{#t} if @var{obj} is a foreign library, or @code{#f}
+otherwise.
+@end deffn
 
-@deffn {Scheme Procedure} dynamic-func name dobj
-@deffnx {C Function} scm_dynamic_func (name, dobj)
-Return a ``handle'' for the func @var{name} in the shared object referred to
-by @var{dobj}. The handle can be passed to @code{dynamic-call} to
-actually call the function.
 
-Regardless whether your C compiler prepends an underscore @samp{_} to the 
global
-names in a program, you should @strong{not} include this underscore in
-@var{name} since it will be added automatically when necessary.
-@end deffn
+@node C Extensions
+@subsection C Extensions
 
-Guile has static support for calling functions with no arguments,
-@code{dynamic-call}.
-
-@deffn {Scheme Procedure} dynamic-call func dobj
-@deffnx {C Function} scm_dynamic_call (func, dobj)
-Call the C function indicated by @var{func} and @var{dobj}.
-The function is passed no arguments and its return value is
-ignored.  When @var{function} is something returned by
-@code{dynamic-func}, call that function and ignore @var{dobj}.
-When @var{func} is a string , look it up in @var{dynobj}; this
-is equivalent to
-@smallexample
-(dynamic-call (dynamic-func @var{func} @var{dobj}) #f)
-@end smallexample
-@end deffn
+The most interesting application of dynamically linked libraries is
+probably to use them for providing @emph{compiled code modules} to
+Scheme programs.  As much fun as programming in Scheme is, every now and
+then comes the need to write some low-level C stuff to make Scheme even
+more fun.
 
-@code{dynamic-call} is not very powerful. It is mostly intended to be
-used for calling specially written initialization functions that will
-then add new primitives to Guile. For example, we do not expect that you
-will dynamically link @file{libX11} with @code{dynamic-link} and then
-construct a beautiful graphical user interface just by using
-@code{dynamic-call}. Instead, the usual way would be to write a special
-Guile-to-X11 glue library that has intimate knowledge about both Guile
-and X11 and does whatever is necessary to make them inter-operate
-smoothly. This glue library could then be dynamically linked into a
-vanilla Guile interpreter and activated by calling its initialization
-function. That function would add all the new types and primitives to
-the Guile interpreter that it has to offer.
-
-(There is actually another, better option: simply to create a
-@file{libX11} wrapper in Scheme via the dynamic FFI. @xref{Dynamic FFI},
-for more information.)
-
-Given some set of C extensions to Guile, the next logical step is to
-integrate these glue libraries into the module system of Guile so that
-you can load new primitives into a running system just as you can load
-new Scheme code.
+Not only can you put these new primitives into their own module (see the
+previous section), you can even put them into a shared library that is
+only then linked to your running Guile image when it is actually
+needed.
 
 @deffn {Scheme Procedure} load-extension lib init
 @deffnx {C Function} scm_load_extension (lib, init)
@@ -225,20 +249,6 @@ well.  For example,
 @end lisp
 @end deffn
 
-@node C Extensions
-@subsection C Extensions
-
-The most interesting application of dynamically linked libraries is
-probably to use them for providing @emph{compiled code modules} to
-Scheme programs.  As much fun as programming in Scheme is, every now and
-then comes the need to write some low-level C stuff to make Scheme even
-more fun.
-
-Not only can you put these new primitives into their own module (see the
-previous section), you can even put them into a shared library that is
-only then linked to your running Guile image when it is actually
-needed.
-
 An example will hopefully make everything clear.  Suppose we want to
 make the Bessel functions of the C library available to Scheme in the
 module @samp{(math bessel)}.  First we need to write the appropriate
@@ -444,15 +454,22 @@ wouldn't it be nice if we didn't have to write any C at 
all? This
 section takes up the problem of accessing C values from Scheme, and the
 next discusses C functions.
 
-@menu
-* Foreign Types::                  Expressing C types in Scheme.
-* Foreign Variables::              Pointers to C symbols.
-* Void Pointers and Byte Access::  Pointers into the ether.
-* Foreign Structs::                Packing and unpacking structs.
-@end menu
+@deffn {Scheme Procedure} foreign-library-pointer lib name
+Return a ``wrapped pointer'' for the symbol @var{name} in the shared
+object referred to by @var{lib}.  The returned pointer points to a C
+object.
+@end deffn
+
+Obsolete note: Regardless whether your C compiler prepends an underscore
+@samp{_} to the global names in a program, you should @strong{not}
+include this underscore in @var{name} since it will be added
+automatically when necessary.
+
+examples
+
 
 @node Foreign Types
-@subsubsection Foreign Types
+@subsection Foreign Types
 
 The first impedance mismatch that one sees between C and Scheme is that
 in C, the storage locations (variables) are typed, but in Scheme types
@@ -515,23 +532,63 @@ In addition, the symbol @code{*} is used by convention to 
denote pointer
 types.  Procedures detailed in the following sections, such as
 @code{pointer->procedure}, accept it as a type descriptor.
 
-@node Foreign Variables
-@subsubsection Foreign Variables
+@node Foreign Functions
+@subsection Foreign Functions
 
-Pointers to variables in the current address space may be looked up
-dynamically using @code{dynamic-pointer}.
+Of course, the land of C is not all nouns and no verbs: there are
+functions too, and Guile allows you to call them.
 
-@deffn {Scheme Procedure} dynamic-pointer name dobj
-@deffnx {C Function} scm_dynamic_pointer (name, dobj)
-Return a ``wrapped pointer'' for the symbol @var{name} in the shared
-object referred to by @var{dobj}.  The returned pointer points to a C
-object.
+The most natural thing to do with a dynamic library is to grovel around
+in it for a function pointer: a @dfn{foreign function}.
+
+@deffn {Scheme Procedure} pointer->procedure return_type func_ptr arg_types @
+                                             [#:return-errno?=#f]
+@deffnx {C Function} scm_pointer_to_procedure (return_type, func_ptr, 
arg_types)
+@deffnx {C Function} scm_pointer_to_procedure_with_errno (return_type, 
func_ptr, arg_types)
 
-Regardless whether your C compiler prepends an underscore @samp{_} to the 
global
-names in a program, you should @strong{not} include this underscore in
-@var{name} since it will be added automatically when necessary.
+Make a foreign function.
+
+Given the foreign void pointer @var{func_ptr}, its argument and
+return types @var{arg_types} and @var{return_type}, return a
+procedure that will pass arguments to the foreign function
+and return appropriate values.
+
+@var{arg_types} should be a list of foreign types.
+@code{return_type} should be a foreign type. @xref{Foreign Types}, for
+more information on foreign types.
+
+If @var{return-errno?} is true, or when calling
+@code{scm_pointer_to_procedure_with_errno}, the returned procedure will
+return two values, with @code{errno} as the second value.
 @end deffn
 
+foreign-library-pointer
+
+Here is a better definition of @code{(math bessel)}:
+
+@example
+(define-module (math bessel)
+  #:use-module (system foreign)
+  #:export (j0))
+
+(define libm (dynamic-link "libm"))
+
+(define j0
+  (pointer->procedure double
+                      (dynamic-func "j0" libm)
+                      (list double)))
+@end example
+
+That's it! No C at all.
+
+more complicated types discussed later, wrapping up with example...
+
+@node Foreign Variables
+@subsection Foreign Variables
+
+Pointers to variables in the current address space may be looked up
+dynamically using @code{dynamic-pointer}.
+
 For example, currently Guile has a variable, @code{scm_numptob}, as part
 of its API. It is declared as a C @code{long}. So, to create a handle
 pointing to that foreign value, we do:
@@ -609,7 +666,7 @@ Unpack the pointer value from a pointer object.
 @end deftypefn
 
 @node Void Pointers and Byte Access
-@subsubsection Void Pointers and Byte Access
+@subsection Void Pointers and Byte Access
 
 Wrapped pointers are untyped, so they are essentially equivalent to C
 @code{void} pointers.  As in C, the memory region pointed to by a
@@ -754,7 +811,7 @@ crash your program, simply accessing the data pointed to by 
a dangling
 pointer or similar can prove equally disastrous.
 
 @node Foreign Structs
-@subsubsection Foreign Structs
+@subsection Foreign Structs
 
 Finally, one last note on foreign values before moving on to actually
 calling foreign functions. Sometimes you need to deal with C structs,
@@ -816,55 +873,8 @@ and @code{pointer->bytevector} routines, one can create 
and parse
 tightly packed structs and unions by hand. See the code for
 @code{(system foreign)} for details.
 
-
-@node Dynamic FFI
-@subsection Dynamic FFI
-
-Of course, the land of C is not all nouns and no verbs: there are
-functions too, and Guile allows you to call them.
-
-@deffn {Scheme Procedure} pointer->procedure return_type func_ptr arg_types @
-                                             [#:return-errno?=#f]
-@deffnx {C Function} scm_pointer_to_procedure (return_type, func_ptr, 
arg_types)
-@deffnx {C Function} scm_pointer_to_procedure_with_errno (return_type, 
func_ptr, arg_types)
-
-Make a foreign function.
-
-Given the foreign void pointer @var{func_ptr}, its argument and
-return types @var{arg_types} and @var{return_type}, return a
-procedure that will pass arguments to the foreign function
-and return appropriate values.
-
-@var{arg_types} should be a list of foreign types.
-@code{return_type} should be a foreign type. @xref{Foreign Types}, for
-more information on foreign types.
-
-If @var{return-errno?} is true, or when calling
-@code{scm_pointer_to_procedure_with_errno}, the returned procedure will
-return two values, with @code{errno} as the second value.
-@end deffn
-
-Here is a better definition of @code{(math bessel)}:
-
-@example
-(define-module (math bessel)
-  #:use-module (system foreign)
-  #:export (j0))
-
-(define libm (dynamic-link "libm"))
-
-(define j0
-  (pointer->procedure double
-                      (dynamic-func "j0" libm)
-                      (list double)))
-@end example
-
-That's it! No C at all.
-
-Numeric arguments and return values from foreign functions are
-represented as Scheme values. For example, @code{j0} in the above
-example takes a Scheme number as its argument, and returns a Scheme
-number.
+@node More Foreign Functions
+@subsection More Foreign Functions
 
 Pointers may be passed to and returned from foreign functions as well.
 In that case the type of the argument or return value should be the
diff --git a/doc/ref/guile.texi b/doc/ref/guile.texi
index 9f3fe2d..e924825 100644
--- a/doc/ref/guile.texi
+++ b/doc/ref/guile.texi
@@ -13,7 +13,7 @@
 @copying
 This manual documents Guile version @value{VERSION}.
 
-Copyright (C) 1996-1997, 2000-2005, 2009-2020 Free Software Foundation,
+Copyright (C) 1996-1997, 2000-2005, 2009-2021 Free Software Foundation,
 Inc.
 
 Permission is granted to copy, distribute and/or modify this document



reply via email to

[Prev in Thread] Current Thread [Next in Thread]