Tomas Mraz wrote:
On Wed, 2006-08-23 at 16:31 -0400, Jesse Keating wrote:On Wednesday 23 August 2006 16:18, Hans de Goede wrote:I just talked to some of our Gnome maintainers and they don't think that's the case at all.Actually afaik gnome and gtk have the exact same problem (they are fully backward compatible but introduce new symbols making apps using these new symbols break on older version), but there we've been plastering over the problem by manually adding Requires to packages.Isn't that why you have foo-so.1 and foo-so.1.1? Your build that has foo-so.1.1 could include foo-so.1 for compat no? Am I totally off base here? Versioned libraries are here for a reason, so that you can know what soname you're compiling against and need later on down the road. Having random symbols in random unversioned .so files seems very very wrong to me, as a shared library.No, they would have to use versioned symbols for this purpose. See http://people.redhat.com/drepper/dsohowto.pdf section 3.
Exported symbol in NSS shared libraries are tagged with the number of the first version that contained the symbol. I used this command to grep for the new symbols in the most recent FC5 update:
[root kaiez1 tmp]# readelf -a /usr/lib/libnss3.so |grep -i 3\.11\.1230: 4f2ed4a0 320 FUNC GLOBAL DEFAULT 11 NSS_RegisterShutdown@@NSS_3.11.1 553: 4f2ed400 151 FUNC GLOBAL DEFAULT 11 NSS_UnregisterShutdown@@NSS_3.11.1 666: 4f3302e0 22 FUNC GLOBAL DEFAULT 11 SEC_ASN1EncodeUnsignedInt@@NSS_3.11.1 749: 4f2f0fc0 86 FUNC GLOBAL DEFAULT 11 SEC_RegisterDefaultHttpCl@@NSS_3.11.1
Description: S/MIME Cryptographic Signature