[Ecls-list] Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME

[Luca Capello]

Hi!

This is a bug in the Debian BTS:

  http://bugs.debian.org/486376

Please don't Cc: me, I read the list.  However, please keep the Debian
bug cc:ed (no need to subscribe), I set the M-F-T and R-T to both the
bug and the mailing list to facilitate the above :-)

I can file this into the SourceForge tracker, if needed/preferred.

On Sun, 15 Jun 2008 19:30:59 +0200, Luca Capello wrote:
> Version: 0.9j-20080306-1

I know that this is not the latest version, but I guess this is still
relevant, since I cannot see anything about SONAME in the ECL ChangeLog:

  http://common-lisp.net/cgi-bin/viewcvs.cgi/ecl/src/CHANGELOG?root=ecl&view=markup

Thx, bye,
Gismo / Luca

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20080825/25e6f692/attachment.sig>