Bug#553109: guile-gnutls: postinst-must-call-ldconfig /usr/lib/libguile-gnutls-v-1.so.0.0.0 by the dynamic library loader. Therefore, the package must call "ldconfig" in its postinst script.

[Andy Wingo]

Hi,

On Fri 30 Oct 2009 22:14, Neil Jerram <neil at ossau.uklinux.net> writes:

> Is it still the case that we recommend guile extensions to be installed
> as normal libraries in /usr/lib, as opposed to some guile-specific
> place?  I think you were recently discussing this, and I'm afraid I
> didn't pay complete attention.

In the alpha 1.9 series you can install them to "extensiondir". From
NEWS:

    ** Dynamically loadable extensions may be placed in a Guile-specific path

    Before, Guile only searched the system library paths for extensions
    (e.g. /usr/lib), which meant that the names of Guile extensions had to
    be globally unique. Installing them to a Guile-specific extensions
    directory is cleaner. Use `pkg-config --variable=extensionsdir
    guile-2.0' to get the location of the extensions directory.

> (Historically this has cropped up several times.  Marius favoured
> /usr/lib on the grounds that it could make sense for some application to
> use a Guile extension library just like a normal C library
> (i.e. application coded in C, linking at build time to the extension
> library and to libguile).  But on the other hand the advantage of
> somewhere like /usr/lib/guile-1.8 is that it makes it easier to handle
> parallel installation, and corresponding correct version numbering,
> without having to have .so names that have both libguile and extension
> version numbers in.

I think the balance goes for parallel installation -- that is,
installing in guile-specific directories. However we do support
dynamically loaded extensions in $libdir as well, for backwards
compatibility. Also I'm not sure it's portable to have a shared module
and be able to link to it.

Andy
-- 
http://wingolog.org/