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 <m...@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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
