Re: Can not work with libguile-2.0

[Mark Harig]

On Fri, Feb 18, 2011 at 09:53:27AM +0100, Andy Wingo wrote:
> > The command listed in section 2.4 "Writing Guile Extensions"
> > should follow the pattern used in section 2.3 "Linking Guile into
> > Programs," namely, add the 'pkg-config' command to provide the
> > appropriate command-line options for the preprocessor, compiler, and
> > linker.
>
> Really?  It doesn't seem to be necessary to actually link to libguile
> there.

OK.  I was suggesting 'pkg-config' for simplicity (i.e., it
is used in the example in the previous section, so let's
continue with that recommended method of looking up
environment variables).  What I suggested was too simple a
solution.

Because statically linking libguile to libguile-bessel.so is
inappropriate, the correct command is to provide the
preprocessor option '-I [path to Guile's header files]'.

Example:

    gcc -I /usr/local/include/guile/2.0 -shared \
        -o libguile-bessel.so -fPIC bessel.c

Then, the problem is to provide clear explanatory text on
how the user can determine what value to provide to the '-I'
switch.

> > In addition, the manual should mention that the environment
> > variable 'PKG_CONFIG_PATH' needs to be set before invoking the
> > compiler.  Something like the following needs to be added, along 
with
> > some explanatory text:
> >
> >  $ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH
>
> Well that isn't quite right, as /usr/local/lib isn't the right place 
for
> libguile-2.0 on many systems.  It's lib64 on my fedora machine.

It's interesting that Guile installed libguile-2.0 in
/usr/local/lib64 on your system.  I have not looked into the
Guile installation process in detail to understand how it
determines where to install its libraries.  But on my system
it is installing 64-bit libraries in the /usr/local/lib
directory tree, while /usr/local/lib64 is empty:

$ file /usr/local/lib/libguile-2.0.so.22.0.0
/usr/local/lib/libguile-2.0.so.22.0.0: ELF 64-bit LSB shared object, 
x86-64, version 1 (SYSV), dynamically linked, not stripped

$ cat /etc/fedora-release
Fedora release 14 (Laughlin)

> I guess we will have to add a section on install prefixes, and the
> relation between -rpath, libtool, PKG_CONFIG_PATH, and
> guile-config.
> Then further compile/link examples can refer back (or
> forwards) to it.

I have not used Guile enough to comment on those specifically, but the
manual should provide a description of whatever is required
for users to (know that they must) specify in order to
create all of the many types of files that Guile supports.

> Perhaps it would be best to assume that Guile is system-installed, and
> note that if linking fails, see some section at the end of 
libguile.texi
> that discusses these issues.
>
> What do you think?

The example command, above, that provides the '-I'
preprocessor option is sufficient to get the source compiled
into a valid library.  It might not work on some systems if
header files are in another directory tree, but at least the
user has been notified about what kinds of information is
needed to compile the file.

In addition, some statement describing what might be
required if the command fails due to variations in
installations should be added.

Suggested:

  "As stated at the beginning of this chapter, examples
   assume that Guile has been installed in the "/usr/local"
   directory tree.  If you have installed Guile in another
   location, then you will need to adjust the value of the
   "-I" option accordingly."

This should be useful both for those who have used a package
installation that puts the files in the "/usr" directory
tree (who would then be providing a redundant "-I /usr"
option) and someone who provided a "-I /usr/local" or "-I
/opt" option.

The basic point is to provide the user with enough
information to understand why the command failed for them.
Otherwise, the user is left to wonder what is wrong with
Guile.  "I did what the manual told me to do, and yet it
does not work.  Did I do something wrong, or is my
installation of Guile broken?"

--