Re: Question about a library that is not creating its *.so* files

[Mike Hommey <mh@glandium.org>]

On Wed, Oct 07, 2009 at 11:42:23AM -0430, Muammar El Khatib wrote:
> Hi Mike and Samuel,
> 
> On Wed, Oct 7, 2009 at 11:24 AM, Mike Hommey <mh@glandium.org> wrote:
> > On Wed, Oct 07, 2009 at 05:49:39PM +0200, Mike Hommey wrote:
> >> On Wed, Oct 07, 2009 at 11:01:05AM -0430, Muammar El Khatib wrote:
> >> > Hi,
> >> >
> >> > I maintain a package which is called CEGUI. In current SID version
> >> > (0.6.2), when you compile it, the next files under usr/lib are
> >> > created:
> >> >
> >> <snip>
> >> >
> >> > As can be seen above, there is no usr/lib/libCEGUI*.so.* files.I have
> >> > looked into the configure file and there is this option:
> >> >
> >> > --enable-shared[=PKGS]  build shared libraries [default=yes]
> >> >
> >> > So I cannot understand,  Why this kind of stuff happen if the shared
> >> > libraries are supposed to be created by default? Maybe this kind of
> >> > question in silly, but what I would like to know is why it happens. I
> >> > will appreciate your comments.
> >>
> >> libname-x.y.z.so is another valid for for libname.so.x.y.z.
> >
> 
> I thought so.
> 
> > That should read: libname-x.y.z.so is another valid form.
> > I'll also add it is (supposed to be) supported by packaging tools.
> 
> So it is not necessary to create symlinks to have  libname.so.x.y.z, isn't it?

Exactly. See /usr/lib/libdb-4.x.so files, for example.

(snip)
> $ objdump -p libCEGUIDevILImageCodec-0.7.0.so | grep SONAME
>   SONAME               libCEGUIDevILImageCodec-0.7.0.so
> 
> They match :)

The question now is to know whether this is the intended SONAME.
With the libname.so.x.y.z form, usually, the SONAME is only
libname.so.x.

This means that libname.so.x.y+1.0 has the same SONAME, while
libname-x.y+1.0 doesn't. If that is the intent, it is fine, but if it is
not, there is a problem.

Mike