Re: libfoo.so.X symlink not created at build time
Hi Bernhard,
On Tue, Jan 04, 2011 at 05:36:37PM +0100, Bernhard R. Link wrote:
> * Muammar El Khatib <muammarelkhatib@gmail.com> [110104 16:52]:
> > I'm maintaining a library which new upstream version is creating at build time
> > *.la, *.so (development symlink), and the library itself with the form
> > libfoo-x.y.z.so but not their symlinks that match their SONAME (I was
> > expecting something like libfoo.so.X).
>
> Please take a look what their actual SONAME is (using readelf -d).
>
Here I am pasting an example:
$ readelf -d libCEGUIBase-0.7.5.so
Dynamic section at offset 0x2e2898 contains 30 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [liblua5.1.so.0]
0x0000000000000001 (NEEDED) Shared library: [libfreetype.so.6]
0x0000000000000001 (NEEDED) Shared library: [libpcre.so.3]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x000000000000000e (SONAME) Library soname: [libCEGUIBase-0.7.5.so]
0x000000000000000c (INIT) 0xeb6c0
0x000000000000000d (FINI) 0x263af8
0x0000000000000004 (HASH) 0x1b8
0x000000006ffffef5 (GNU_HASH) 0xb2c0
0x0000000000000005 (STRTAB) 0x42750
0x0000000000000006 (SYMTAB) 0x18198
0x000000000000000a (STRSZ) 381724 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000003 (PLTGOT) 0x4e5bb0
0x0000000000000002 (PLTRELSZ) 51288 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0xdee68
0x0000000000000007 (RELA) 0xa33d8
0x0000000000000008 (RELASZ) 244368 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffe (VERNEED) 0xa32e8
0x000000006fffffff (VERNEEDNUM) 6
0x000000006ffffff0 (VERSYM) 0x9fa6c
0x000000006ffffff9 (RELACOUNT) 177
0x0000000000000000 (NULL) 0x0
> While the SONAME usually is something like libfoo.so.X, it might also be
> anything else (and the dynamic linker will that look for that file at
> runtime). If the SONAME is not libfoo.so.X there is no need to have a
> symlink of that name.
>
I think I have understood you. So, in this case I am showing I don't need the
symlinks of type libfoo.so.X because the SONAME is itself the libfoo-x.y.z.so.
> If you have something like libfoo-X.so there, then this is not a
> development symlink, but the SONAME symlink. (so if any doc says
> .so.X they mean -X.so in that case and if they say .so they mean the
> real .so file and not the -X.so).
>
Then, I should provide in the library package _only_ the lib*-x.y.z.so files,
and obviously the *.la and *.so development symlinks into -dev package. Please,
correct me if I am wrong.
Now, packages which depends on this library to build are going to fail with this
change. It can be said that a library transition has to be done. I'll rebuild
packages gotten by executing apt-cache rdepends, and contact maintainers. Could
it be said that a "safe" upload would be when at least all those dependent
packages have a workaround (in case of failing to build)?. I am sorry for these
questions as basic as they can seem. It's my first time facing a library
transition, and for what I have read I am aware of the complexity of it.
> As stupid as this is (especially the mixing of namespaces for
> filenames), there are sadly enough libraries already doing it this way
> and there is technically no problem with it.
Thanks for the information and your help,
--
Muammar El Khatib.
Linux user: 403107.
Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1
http://muammar.me | http://proyectociencia.org
,''`.
: :' :
`. `'
`-
Reply to: