Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME

[Luca Capello]

Package: ecl
Version: 0.9j-20080306-1
Severity: normal
Tags: help

Hello,

lintian complains about a missing SONAME for /usr/lib/libecl.so:

--8<---------------cut here---------------start------------->8---
E: ecl: sharedobject-in-library-directory-missing-soname usr/lib/libecl.so
N:
N:   A shared object was identified in a library directory (i.e. a
N:   directory in the standard linker path) which doesn't have a SONAME.
N:   This is usually an error.
N:   
N:   SONAMEs are set with something like gcc -Wl,-soname,libfoo.so.0, where
N:   0 is the major version of the library. If your package uses libtool,
N:   then libtool invoked with the right options should be doing this.
N:
--8<---------------cut here---------------end--------------->8---

It seems this was already discussed back in March 2006, but without a
final decision ([1] and [2]):

=====
On Mon, 06 Mar 2006 12:09:12 +0100, René van Bevern wrote:
> On Mon, 06 Mar 2006 10:42:26 +0100, Peter Van Eynde wrote:
>> On Sunday 05 March 2006 12:14, René van Bevern wrote:
>>> commented out, because there is (should be) a better way to handle
>>> it: each ECL binary links with libecl.so, so the ecl package -- once
>>> it comes into Debian -- should bring a shlibs description and
>>> dh_shlibdeps should better solve this dependency. In case somebody
>>> proves me wrong and it turns out that shlibs don't work well in this
>>> case, I can just uncomment this code. ;-)
>>
>> This is still an open issue for the ecl port, which started working
>> last Friday (it installs and creates a clc v5 aware ecl binary just
>> fine). The libecl.so file is not a 'library' in a traditional sense
>> in that it publishes an API that C programs can use. I assume there
>> is a stronger connection between a ecl-generated program and the ecl
>> version as a whole then what you would expect from the library alone.
>
> So does it make sense to have a separate libecl package?
>
> I really don't have deep knowledge of ECL's internals, sorry. That's
> why I have written the preliminary code for ECL-dependency handling in
> dh-lisp.
>
> libecl.so differs from "normal" libraries in at least the thing that
> it does not provide a SONAME (which might already make the shlibs
> system awkward to use in this case). I also don't know if ECL
> generated programs need only libecl or more.
=====

Since I'm not a library expert and still a newbie with ECL, I'm looking
for help :-D

Thx, bye,
Gismo / Luca

Footnotes: 
[1] Message-Id: <200603061042.28217.cl-debian at pvaneynd.mailworks.org>
    http://common-lisp.net/pipermail/cl-debian/2006-March/001083.html
[2] Message-ID: <87ek1f25k7.fsf at negoyl.progn.org>
    http://common-lisp.net/pipermail/cl-debian/2006-March/001084.html

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-rc5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ecl depends on:
ii  common-lisp-controller    6.15           Common Lisp source and compiler ma
ii  libc6                     2.7-12         GNU C Library: Shared libraries
ii  libgc-dev                 1:6.8-1.1      conservative garbage collector for
ii  libgc1c2                  1:6.8-1.1      conservative garbage collector for
ii  libgmp3-dev               2:4.2.2+dfsg-3 Multiprecision arithmetic library 
ii  libgmp3c2                 2:4.2.2+dfsg-3 Multiprecision arithmetic library
ii  libncurses5-dev           5.6+20080531-1 Developer's libraries and docs for

ecl recommends no packages.

-- no debconf information
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20080615/cd26e4be/attachment.pgp