Hi Bernhard, On Tue, Jan 04, 2011 at 05:36:37PM +0100, Bernhard R. Link wrote: > * Muammar El Khatib <[email protected]> [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 ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
