Can not work with libguile-2.0

Can not work with libguile-2.0

[Fu-Gangqiang]

Hi,all
I learn guile from manual,and I can not work with libguile and find some manual bugs.

scheme@(guile-user)> (version)
$1 = "2.0.0"
$ build-aux/config.guess 
i686-pc-linux-gnu
$ uname -a
Linux 2.6.32-28-generic #55-Ubuntu SMP i686 GNU/Linux
 $ ./config.status  --config
'--disable-deprecated' 'BDW_GC_CFLAGS=-L/usr/local/lib' 'BDW_GC_LIBS=-lgc'

In manual section 2.3(Linking Guile into Programs)

I follow the example,run it and have something wrong:
---->cut here<----
$ gcc -o simple-guile simple-guile.c  `pkg-config --cflags --libs guile-2.0`
$ ./simple-guile 
./simple-guile: error while loading shared libraries: libguile-2.0.so.22: cannot open shared object file: No such file or directory
---->cut here<----
but I have libguile-2.0.so.22 installed in /usr/local/lib directroy
$ pkg-config --cflags --libs guile-2.0
-pthread -L/usr/local/lib -I/usr/local/include/guile/2.0  -L/usr/local/lib -lguile-2.0 -lgc  
$ ls /usr/local/lib | grep libguile
libguile-2.0.a
libguile-2.0.la
libguile-2.0.so
libguile-2.0.so.22
libguile-2.0.so.22.0.0
libguilereadline-v-18.a
libguilereadline-v-18.la
libguilereadline-v-18.so
libguilereadline-v-18.so.18
libguilereadline-v-18.so.18.0.0

when I follow section 5.1.2(A Sample Guile Main Program) using Autoconf tools also have some problem:
<I do not know how to use the autoconf tool, I just follow the giving example>
$ aclocal
$ autoconf
$ ./configure
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
./configure: line 2490: GUILE-FLAGS: command not found
configure: creating ./config.status
config.status: creating Makefile
$ make
gcc -c @GUILE_CFLAGS@ simple-guile.c
gcc: @GUILE_CFLAGS@: No such file or directory
simple-guile.c:1:22: error: libguile.h: No such file or directory
make: *** [simple-guile.o] Error 1

And in section 2.4(Writing Guile Extensions)
There are some deprecated functions in the example,also in the section 5.2.1(A Sample Guile Extension)
I use scm_from_double,scm_to_double instead,
I run the mannal cmd and also have something wrong:
---->cut here<----
$ gcc -shared -o libguile-bessel.so -fPIC t1.c 
t1.c:2:22: error: libguile.h: No such file or directory
t1.c:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘j0_wrapper’
t1.c: In function ‘init_bessel’:
t1.c:13: error: ‘j0_wrapper’ undeclared (first use in this function)
t1.c:13: error: (Each undeclared identifier is reported only once
t1.c:13: error: for each function it appears in.)
---->cut here<----
But when I run cmd:
gcc -shared -o libguile-bessel.so -fPIC t1.c `pkg-config --cflags --libs guile-2.0`
everything is OK!

Re: Can not work with libguile-2.0

[Hans Aberg]

On 17 Feb 2011, at 13:02, Fu-Gangqiang wrote:

> I learn guile from manual,and I can not work with libguile and find some manual bugs.

> In manual section 2.3(Linking Guile into Programs)
> 
> I follow the example,run it and have something wrong:
> ---->cut here<----
> $ gcc -o simple-guile simple-guile.c  `pkg-config --cflags --libs guile-2.0`
> $ ./simple-guile 
> ./simple-guile: error while loading shared libraries: libguile-2.0.so.22: cannot open shared object file: No such file or directory
> ---->cut here<----
> but I have libguile-2.0.so.22 installed in /usr/local/lib directroy

I use the flags
  `guile-config compile`
  `guile-config link`

  Hans

Re:Re: Can not work with libguile-2.0

[Fu-Gangqiang]

"Hans Aberg" <haberg-1@telia.com> wrote:
>I use the flags
>  `guile-config compile`
>  `guile-config link`

I try to use guile-config, but have the same problem:
$ gcc -o simple-guile simple-guile.c  `guile-config compile` `guile-config link`
~/Test/scm $ ./simple-guile
./simple-guile: error while loading shared libraries: libguile-2.0.so.22: cannot open shared object file: No such file or directory

guile-config and pkg-config have the same effect
$ guile-config compile; guile-config link
-pthread -L/usr/local/lib -I/usr/local/include/guile/2.0  
-L/usr/local/lib -lguile-2.0 -lgc  
$ pkg-config --cflags --libs guile-2.0
-pthread -L/usr/local/lib -I/usr/local/include/guile/2.0  -L/usr/local/lib -lguile-2.0 -lgc

Re: Can not work with libguile-2.0

[Mark Harig]

>
> In manual section 2.3(Linking Guile into Programs)
>
> I follow the example,run it and have something wrong:
> ---->cut here<----
> $ gcc -o simple-guile simple-guile.c  `pkg-config --cflags --libs 
guile-2.0`
> $ ./simple-guile
> ./simple-guile: error while loading shared libraries: 
libguile-2.0.so.22: cannot
> open shared object file: No such file or directory
> ---->cut here<----

Agreed.  The solution to the problem above, for now, is to set the
value of the environment variable LD_LIBRARY_PATH so that the linker
can find libguile-2.0.so.22:

   $ export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
   $ guile
   ...

The value that you set LD_LIBRARY_PATH depends on where you installed
Guile.  You should adjust the value accordingly, depending on where
libguile-2.0.so.22 is located in your file system.

This problem has been reported.  See the following messages:

http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00022.html
http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00036.html
http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00038.html
http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00077.html
http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00076.html
http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00079.html

--

Re: Can not work with libguile-2.0

[Mark Harig]

> And in section 2.4(Writing Guile Extensions)
> There are some deprecated functions in the example

Agreed.  The example code uses deprecated functions.  It would better
if the developers of Guile were to provide some idiomatic code that
shows the best practice that they recommend programmers use.

Here is the C code in the reference manual:

     #include <math.h>
     #include <libguile.h>

     SCM
     j0_wrapper (SCM x)
     {
       return scm_make_real (j0 (scm_num2dbl (x, "j0")));
     }

     void
     init_bessel ()
     {
       scm_c_define_gsubr ("j0", 1, 0, 0, j0_wrapper);
     }

scm_make_real and scm_num2dbl are included in deprecated.h:

SCM_DEPRECATED SCM scm_make_real (double x);
SCM_DEPRECATED double scm_num2dbl (SCM a, const char * why);

The fact that these functions are marked as deprecated is saying that
Guile recommends that they no longer be used, so it is contradictory
for the manual to include them in example code.

--

Re: Can not work with libguile-2.0

[Andy Wingo]

Hello,

On Thu 17 Feb 2011 19:23, Mark Harig <idirectscm@aim.com> writes:

>> And in section 2.4(Writing Guile Extensions)
>> There are some deprecated functions in the example
>
> Agreed.  The example code uses deprecated functions.  It would better
> if the developers of Guile were to provide some idiomatic code that
> shows the best practice that they recommend programmers use.

Agreed, thanks for catching this; fixed.  Patches fixing problems like
this are most welcome in the future.  NEWS should contain details about
deprecated functions and their replacements.

Cheers,

Andy

-- 
http://wingolog.org/

Re: Can not work with libguile-2.0

[Mark Harig]

> I run the mannal cmd and also have something wrong:
> ---->cut here<----
> $ gcc -shared -o libguile-bessel.so -fPIC t1.c
> t1.c:2:22: error: libguile.h: No such file or directory
> t1.c:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before
> ‘j0_wrapper’
> t1.c: In function ‘init_bessel’:
> t1.c:13: error: ‘j0_wrapper’ undeclared (first use in this function)
> t1.c:13: error: (Each undeclared identifier is reported only once
> t1.c:13: error: for each function it appears in.)
> ---->cut here<----
> But when I run cmd:
> gcc -shared -o libguile-bessel.so -fPIC t1.c `pkg-config --cflags 
--libs
> guile-2.0`
> everything is OK!

Agreed.  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.  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
   $ gcc -shared -o libguile-bessel.so -fPIC t1.c `pkg-config --cflags 
--libs guile-2.0`

The manual should provide this extra detail so that new users can
simply follow the steps listed without having to refer to external
documents.

--

Re: Can not work with libguile-2.0

[Andy Wingo]

On Thu 17 Feb 2011 20:08, Mark Harig <idirectscm@aim.com> writes:

> 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.

> 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.

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.
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?

Andy
-- 
http://wingolog.org/

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?"

--

Re: Can not work with libguile-2.0

[Andy Wingo]

Hi Mark,

On Fri 18 Feb 2011 20:42, Mark Harig <idirectscm@aim.com> writes:

>     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.

I agree that we should be using pkg-config; I was just objecting to
adding --libs.

>> > 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.

That's not quite it; the default libdir is still $prefix/lib.  But on
Fedora systems, "lib" is for 32-bit libs, and "lib64" is for 64-bit
libs.  If you install a library into "lib" you will then end up having
to add the 32-bit libdir to your -L path, which is a path to madness.

What I'm saying is that if we make assumptions about where Guile goes,
we need to be explicit about them in the manual.

Cheers,

Andy
-- 
http://wingolog.org/

Re: Can not work with libguile-2.0

[Fu-Gangqiang]

At 2011-02-18 02:04:08，"Mark Harig" <idirectscm@aim.com> wrote:>

 > $ export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
yes, I didnt set the LD_LIBRARY_PATH varialbe
after I set it, simple-guile worked

Thinks for the links:
> This problem has been reported.  See the following messages:
> 
> http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00022.html
> http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00036.html
> http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00038.html
> http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00077.html
> http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00076.html
> http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00079.html

Re: Can not work with libguile-2.0

[Andy Wingo]

Hi Mark, Bruno, and Fu-Gangqiang,

Fu-Gangqiang writes:

> In manual section 2.3(Linking Guile into Programs)
>
> I follow the example,run it and have something wrong:
> ---->cut here<----
> $ gcc -o simple-guile simple-guile.c  `pkg-config --cflags --libs guile-2.0`
> $ ./simple-guile 
> ./simple-guile: error while loading shared libraries: libguile-2.0.so.22: cannot open shared object file: No such file or directory

Bruno Haible first brought up the issues here:

  http://lists.gnu.org/archive/html/libtool/2001-11/msg00050.html

I don't know of a consensus for the solution, so I'm copying him on the
mail here.  Bruno, what should we recommend in the manual that users do
to link to Guile, and produce an executable that correctly finds
libguile when it is run?

Thanks in advance,

Andy
-- 
http://wingolog.org/

Re: linking with libguile-2.0, rpath

[Bruno Haible]

[-- Attachment #1: Type: text/plain, Size: 4276 bytes --]

Hi Andy,

> > $ gcc -o simple-guile simple-guile.c  `pkg-config --cflags --libs guile-2.0`
> > $ ./simple-guile 
> > ./simple-guile: error while loading shared libraries: libguile-2.0.so.22: cannot open shared object file: No such file or directory
> 
> Bruno Haible first brought up the issues here:
> 
>   http://lists.gnu.org/archive/html/libtool/2001-11/msg00050.html
> 
> I don't know of a consensus for the solution, so I'm copying him on the
> mail here.

A lot of progress has been made on this since 2001. You now find in gnulib
a module 'havelib', consisting essentially of a file lib-link.m4 and a file
config.rpath, that determine the appropriate flags for encoding the rpath
(runtime search path) in an executable or shared library.

> Bruno, what should we recommend in the manual that users do 
> to link to Guile, and produce an executable that correctly finds
> libguile when it is run?

First of all, the macro GUILE_FLAGS in guile.m4 needs to be extended.
Find attached a patch that does 3 things:
  - Fix the documentation of GUILE_CFLAGS to mention that it may contain
    several -I options. (It did for me, because I had bdw-gc installed at
    a different location than guile.)
  - Fix the documentation of GUILE_LDFLAGS to mention that it contains
    flags for the compiler, not for the linker (you use it with $CC, not
    with 'ld'), that it may contain several -L options (as it did for me),
    and that it is usually insufficient for producing working programs.
  - Define variables GUILE_LIBS and GUILE_LTLIBS that can be used instead
    of GUILE_LDFLAGS and that produce working programs. One is for use
    with the compiler, the other one for use with libtool. (GUILE_LDFLAGS
    contains options like -Wl,-rpath that libtool would not understand,
    and GUILE_LTLIBS contains options like -R that the compiler would not
    understand.)

For example, I put these lines into a configure.ac

  GUILE_FLAGS
  echo "GUILE_LIBS = $GUILE_LIBS"
  echo "GUILE_LTLIBS = $GUILE_LTLIBS"

and got this output, as expected:

checking libguile compile flags... -Wall -pthread -I/arch/x86_64-linux/gnu-inst-guile/2.0.0/include/guile/2.0 -I/arch/x86_64-linux/gnu-inst-libunistring/0.9.3/include -I/arch/x86_64-linux/gnu/include  
checking libguile link flags... -L/arch/x86_64-linux/gnu-inst-guile/2.0.0/lib64 -L/arch/x86_64-linux/gnu/lib64 -lguile-2.0 -lgc  
GUILE_LIBS = -L/arch/x86_64-linux/gnu-inst-guile/2.0.0/lib64 -L/arch/x86_64-linux/gnu/lib64 -lguile-2.0 -lgc   -Wl,-rpath -Wl,/arch/x86_64-linux/gnu-inst-guile/2.0.0/lib64 -Wl,-rpath -Wl,/arch/x86_64-linux/gnu/lib64
GUILE_LTLIBS = -L/arch/x86_64-linux/gnu-inst-guile/2.0.0/lib64 -L/arch/x86_64-linux/gnu/lib64 -lguile-2.0 -lgc   -R/arch/x86_64-linux/gnu-inst-guile/2.0.0/lib64 -R/arch/x86_64-linux/gnu/lib64

Second, about the documentation. A command line

  $ gcc -o simple-guile simple-guile.c  `pkg-config --cflags --libs guile-2.0`

cannot work in general, because the list of directories to use in the -rpath
option(s) comes from pkg-config, but it needs to be presented in a syntax that
depends on the compiler (think of Solaris, where the option for gcc is
-Wl,-rpath and the option for cc is -R), and pkg-config does not know about the
compiler.

That's also the reason why I propose to add this logic to the GUILE_FLAGS macro
and not to the 'guile-config' program.

So, for the documentation, I only see an ad-hoc approach:

# Define a function that transform -L options to rpath options. This definition
# works with gcc on glibc systems. On other platforms, the details are different.
$ transform_L_options_to_rpath_options ()
{
  sed -e 's/^/ /' | sed -e 's/ -l *[^ ]*//g' -e 's/ -L */ -Wl,-rpath -Wl,/g'
}

With this, the command line becomes

$ gcc -o simple-guile simple-guile.c
      `pkg-config --cflags --libs guile-2.0`
      `pkg-config --libs guile-2.0 | transform_L_options_to_rpath_options`

or with the use of guile-config:

$ gcc -o simple-guile simple-guile.c \
      `guile-config compile` \
      `guile-config link` \
      `guile-config link | transform_L_options_to_rpath_options`

Bruno

-- 
In memoriam Friedrich Weißler <http://en.wikipedia.org/wiki/Friedrich_Weißler>

[-- Attachment #2: guile.m4.diff --]
[-- Type: text/x-diff, Size: 3244 bytes --]

2011-02-19  Bruno Haible  <bruno@clisp.org>

	Add support for linking against guile with rpath.
	* guile.m4 (GUILE_FLAGS): Also set GUILE_LIBS and GUILE_LTLIBS. Fix
	documentation.

--- guile.m4.bak	2011-02-19 14:32:23.000000000 +0100
+++ guile.m4	2011-02-19 15:33:26.000000000 +0100
@@ -70,29 +70,56 @@
 #
 # This macro runs the @code{guile-config} script, installed with Guile, to
 # find out where Guile's header files and libraries are installed.  It sets
-# two variables, @var{GUILE_CFLAGS} and @var{GUILE_LDFLAGS}.
+# four variables, @var{GUILE_CFLAGS}, @var{GUILE_LDFLAGS}, @var{GUILE_LIBS},
+# and @var{GUILE_LTLIBS}.
 #
 # @var{GUILE_CFLAGS}: flags to pass to a C or C++ compiler to build code that
-# uses Guile header files.  This is almost always just a @code{-I} flag.
+# uses Guile header files.  This is almost always just one or more @code{-I}
+# flags.
 #
-# @var{GUILE_LDFLAGS}: flags to pass to the linker to link a program against
+# @var{GUILE_LDFLAGS}: flags to pass to the compiler to link a program against
 # Guile.  This includes @code{-lguile} for the Guile library itself, any
 # libraries that Guile itself requires (like -lqthreads), and so on.  It may
-# also include a @code{-L} flag to tell the compiler where to find the
-# libraries.
+# also include one or more @code{-L} flag to tell the compiler where to find
+# the libraries.  But it does not include flags that influence the program's
+# runtime search path for libraries, and will therefore lead to a program
+# that fails to start, unless all necessary libraries are installed in a
+# standard location such as @file{/usr/lib}.
+#
+# @var{GUILE_LIBS} and @var{GUILE_LTLIBS}: flags to pass to the compiler or to
+# libtool, respectively, to link a program against Guile.  It includes flags
+# that augment the program's runtime search path for libraries, so that shared
+# libraries will be found at the location where they were during linking, even
+# in non-standard locations.  @var{GUILE_LIBS} is to be used when linking the
+# program directly with the compiler, whereas @var{GUILE_LTLIBS} is to be used
+# when linking the program is done through libtool.
 #
 # The variables are marked for substitution, as by @code{AC_SUBST}.
 #
 AC_DEFUN([GUILE_FLAGS],
- [AC_REQUIRE([GUILE_PROGS])dnl
+ [dnl Find guile-config.
+  AC_REQUIRE([GUILE_PROGS])dnl
+
   AC_MSG_CHECKING([libguile compile flags])
   GUILE_CFLAGS="`$GUILE_CONFIG compile`"
   AC_MSG_RESULT([$GUILE_CFLAGS])
+
   AC_MSG_CHECKING([libguile link flags])
   GUILE_LDFLAGS="`$GUILE_CONFIG link`"
   AC_MSG_RESULT([$GUILE_LDFLAGS])
-  AC_SUBST(GUILE_CFLAGS)
-  AC_SUBST(GUILE_LDFLAGS)
+
+  dnl Determine the platform dependent parameters needed to use rpath.
+  dnl AC_LIB_LINKFLAGS_FROM_LIBS is defined in gnulib/m4/lib-link.m4 and needs
+  dnl the file gnulib/build-aux/config.rpath.
+  AC_LIB_LINKFLAGS_FROM_LIBS([GUILE_LIBS], [$GUILE_LDFLAGS], [])
+  GUILE_LIBS="$GUILE_LDFLAGS $GUILE_LIBS"
+  AC_LIB_LINKFLAGS_FROM_LIBS([GUILE_LTLIBS], [$GUILE_LDFLAGS], [yes])
+  GUILE_LTLIBS="$GUILE_LDFLAGS $GUILE_LTLIBS"
+
+  AC_SUBST([GUILE_CFLAGS])
+  AC_SUBST([GUILE_LDFLAGS])
+  AC_SUBST([GUILE_LIBS])
+  AC_SUBST([GUILE_LTLIBS])
  ])
 
 # GUILE_SITE_DIR -- find path to Guile "site" directory

Re: linking with libguile-2.0, rpath

[Andy Wingo]

Hi Bruno,

Thanks for looking into this matter.

On Sat 19 Feb 2011 16:30, Bruno Haible <bruno@clisp.org> writes:

> First of all, the macro GUILE_FLAGS in guile.m4 needs to be extended.
> Find attached a patch that does 3 things:

Thanks!  Applied.

> Second, about the documentation. A command line
>
>   $ gcc -o simple-guile simple-guile.c  `pkg-config --cflags --libs guile-2.0`
>
> cannot work in general, because the list of directories to use in the -rpath
> option(s) comes from pkg-config, but it needs to be presented in a syntax that
> depends on the compiler (think of Solaris, where the option for gcc is
> -Wl,-rpath and the option for cc is -R), and pkg-config does not know about the
> compiler.
>
> That's also the reason why I propose to add this logic to the GUILE_FLAGS macro
> and not to the 'guile-config' program.

I don't know how I was unaware of this for so long; libtool-induced
bliss (!) I guess.

> So, for the documentation, I only see an ad-hoc approach:
>
> # Define a function that transform -L options to rpath options. This definition
> # works with gcc on glibc systems. On other platforms, the details are different.
> $ transform_L_options_to_rpath_options ()
> {
>   sed -e 's/^/ /' | sed -e 's/ -l *[^ ]*//g' -e 's/ -L */ -Wl,-rpath -Wl,/g'
> }
>
> With this, the command line becomes
>
> $ gcc -o simple-guile simple-guile.c
>       `pkg-config --cflags --libs guile-2.0`
>       `pkg-config --libs guile-2.0 | transform_L_options_to_rpath_options`

Food for thought.  Thanks for the suggestion.

Cheers,

Andy
-- 
http://wingolog.org/