should remain unchanged during a stable series. Currently that means
that it omits the micro version. The effective version should be used
for items like the versioned share directory name
-i.e. @file{/usr/share/guile/1.6/}
+i.e.@: @file{/usr/share/guile/1.6/}
@lisp
(version) @result{} "1.6.0"
@end table
Values are all strings. The value for @code{LIBS} is typically found
-also as a part of "guile-config link" output. The value for
+also as a part of @code{pkg-config --libs
+guile-@value{EFFECTIVE-VERSION}} output. The value for
@code{guileversion} has form X.Y.Z, and should be the same as returned
-by @code{(version)}. The value for @code{libguileinterface} is
-libtool compatible and has form CURRENT:REVISION:AGE
-(@pxref{Versioning,, Library interface versions, libtool, GNU
-Libtool}). The value for @code{buildstamp} is the output of the
-command @samp{date -u +'%Y-%m-%d %T'} (UTC).
+by @code{(version)}. The value for @code{libguileinterface} is libtool
+compatible and has form CURRENT:REVISION:AGE (@pxref{Versioning,,
+Library interface versions, libtool, GNU Libtool}). The value for
+@code{buildstamp} is the output of the command @samp{date -u +'%Y-%m-%d
+%T'} (UTC).
In the source, @code{%guile-build-info} is initialized from
libguile/libpath.h, which is completely generated, so deleting this file
In general, a particular feature may be available for one of two
reasons. Either because the Guile library was configured and compiled
-with that feature enabled --- i.e. the feature is built into the library
+with that feature enabled --- i.e.@: the feature is built into the library
on your system. Or because some C or Scheme code that was dynamically
loaded by Guile has added that feature to the list.