On Fri, 2013-02-01 at 18:30 +0100, Ludovic Courtès wrote: > Dmitry Roshchin <dmi...@roshchin.org> skribis: > > > On Tuesday 22 January 2013 23:09:51 Ludovic Courtès wrote: > >> Hi, > >> > >> Dmitry Roshchin <dmi...@roshchin.org> 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’. > >
