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@pvaneynd.mailworks.org> http://common-lisp.net/pipermail/cl-debian/2006-March/001083.html [2] Message-ID: <87ek1f25k7.fsf@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