octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SONAMES for Octave's libraries


From: Thomas Weber
Subject: SONAMES for Octave's libraries
Date: Sat, 20 May 2006 19:24:57 +0200

Hi,

sorry for the long mail, a summary of this mail is as follows:
Is there a chance to have SONAME versioning for the three shared
libraries of Octave, namely
        libcruft.so  
        liboctave.so  
        liboctinterp.so
and thus put the libraries under /usr/lib and not under a special
subdirectory?


Current versions of Octave don't use SONAME versioning for the shared
libraries; instead, the shared libraries are put under a subdirectory
of /usr/lib and the octave executable gets an rpath for this directory:

$ objdump -p /usr/bin/octave | grep RPATH
        RPATH       /usr/lib/octave-2.1.73

$ ls -l /usr/lib/octave-2.1.73/          
        libcruft.so -> libcruft.so.2.1.73
        libcruft.so.2.1.73
        liboctave.so -> liboctave.so.2.1.73
        liboctave.so.2.1.73
        liboctinterp.so -> liboctinterp.so.2.1.73
        liboctinterp.so.2.1.73

Normal .oct files don't know about the subdirectory and therefore the
linker can't find the libs:
$ ldd /usr/lib/octave/2.1.73//oct/i486-pc-linux-gnu/givens.oct 
        linux-gate.so.1 =>  (0xffffe000)
        libcruft.so => not found
        liboctave.so => not found
        liboctinterp.so => not found

This is no problem, as these files are only called via the interpreter
which then knows where to find these libs.


The problem arises if programs link to the shared libraries directly, as
does Octave-Workshop:
$ ldd octave-workshop
        liboctinterp.so => /usr/lib/octave-2.1.73/liboctinterp.so
        liboctave.so => /usr/lib/octave-2.1.73/liboctave.so (0xa691d000)
        libcruft.so => /usr/lib/octave-2.1.73/libcruft.so (0xa68cb000)
$ objdump -p octave-workshop | grep -i rpath
  RPATH       /lib:/usr/lib/octave-2.1.73

So, if one updates to a new version of Octave (say 2.1.74), Octave
Workshop will break, which means a recompile of Workshop every time a
new version of Octave is released. Additionally, prelinking doesn't work
(though I consider this to be a minor issue).


Some information:
SONAME, API, ABI:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi

Things that change the ABI (which is the important part for a SONAME
change) in C++:
http://www.trolltech.com/developer/faqs/362


Now, I'm not sure when Octave's api_version is bumped, but it might make
a good candidate for the soname numbering.

Regards
        Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]