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

[Luca Capello]

Hi Juanjo!

On Sat, 30 Aug 2008 09:19:19 +0200, Juan Jose Garcia-Ripoll wrote:
> On Sat, Aug 30, 2008 at 1:07 AM, Luca Capello <luca at pca.it> wrote:
>> This bug has nothing to do with the rpath issue (now solved [1]).
>> Thus, the problem remains: is there any particular reason for
>> /usr/lib/libecl.so not providing a SONAME?
>
> That is not something ECL has to provide. It is more a configuration
> option that operating systems may provide.

Sorry, I'm not a skilled programmed, but I don't understand why this is
not ECL task: ECL provides the libecl.so library, so who else should
provide its SONAME?

> You have to consider the following: with every binary release we are
> adding more functions and the names of old ones change. That means
> being a rapidly evolving project we are definitely going to break
> binary compatibility very frequently.

Isn't this the reason for SONAME existence?  At least this is how I see
it and it seems that others share my view [1][2].

> I should rather say with every release.

This means that you need to update the SONAME for every release.  And I
don't see this as a stopper.

> Furthermore, ECL is currently not being used as a library by any
> project. It is only either a runtime for compiled files or the
> interpreted environment itself.

However a standalone program [3] works out of the box with just
libecl.so, doesn't it?  This means that while ecl (the executable) is
not used as a library, libecl.so acts like a *real* library (as Gabriel
Dos Reis already pointed out [4]).  Thus, without a SONAME and from a
simple `ldd` output, there's no way to know which ECL versions the
program was built with.

> Do you expect SBCL to use some kind of SONAME for its core? Not
> really.

SBCL doesn't provide any library which can be used *without* its core
(thus they are installed into /usr/lib/sbcl/, the same being true for
e.g. CLISP).  Similarly, the ECL "libraries" needed for the core reside
in /usr/lib/ecl/ and don't need any SONAME.

In the next days I'll upload a new Debian version for ECL to solve bug
#495756 [5] in time for the lenny release [6].  I'd like to solve this
issue as well, is it possible?

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://mail-index.netbsd.org/tech-toolchain/1998/07/17/0000.html
[2] http://wiki.linuxquestions.org/wiki/Library-related_Commands_and_Files#soname
    NB, not that I blindly trust random wikis...
[3] New manual: "1.6.3. Example of standalone program"
[4] Message-ID: <206fcf960808300836h69a9ecc5heaba09277f08b84e at mail.gmail.com>
[5] http://bugs.debian.org/495756
[6] http://wiki.debian.org/DebianLenny
-------------- 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/20080903/e3d427e5/attachment.sig>