Re: libguilereadline load

[Nala Ginrut]

On Fri, 2013-02-01 at 18:30 +0100, Ludovic Courtès wrote:
> Dmitry Roshchin <address@hidden> skribis:
> 
> > On Tuesday 22 January 2013 23:09:51 Ludovic Courtès wrote:
> >> Hi,
> >> 
> >> Dmitry Roshchin <address@hidden> skribis:
> >> > Is it normal, that guile tries to load "libguilereadline-v-18.so" instead
> >> > of "libguilereadline-v-18.so.18"? Guile  version - 2.0.7.
> >> 
> >> You normally have both, as well as libguilereadline-v-18.la, no?
> >> 
> >> Guile uses ltdl for dynamic loading (info "(libtool) Using libltdl").
> >> The rule is to first search for .la files.  The .la file tells ltdl that
> >> the real library is the .so.18 file, which ltdl then loads.
> >> 
> >> When the .la file is missing, ltdl tries the .so file instead (not the
> >> .so.18 file).
> >> 
> >
> > openSUSE packaging policy requires to remove .la files. And .so file is 
> > contained in guile-devel package. So  it doesn't work by default.
> 
> I see.  The problem is that Guile has no way of guessing the .18
> extension (it’s a platform-specific extension computed by libtool.)
> 
> Debian has a similar policy IIRC, but they ship the .so file as part of
> the ‘guile-2.0-libs’ package, perhaps as an exception:
> 
>   http://packages.debian.org/sid/hurd-i386/guile-2.0-libs/filelist
> 

hmm...almost all 'shared lib packaging policy' needs *-dev package
contains the *.so link to a related versioned library. It's not so easy
to persuade them to make an exception if we don't have a solid reason.
Can you tell me how to do a special detect for loading .18? If the
suggestion failed, at least we have a platform specific patch to fix
that.   

> Perhaps you could suggest that openSUSE do the same?
> 
> Ludo’.
> 
>