Jakub Wilk wrote: > I don't claim to be an expert on symbol versioning, but I did some > experiments, and it doesn't seem to be the case. If a program is linked to > two versions of a library, one of which doesn't use versioned symbols, then > the symbols from the directly-linked one shadows the other.
Thanks. I made the same experiment (application X linked directly to library A and linked via library C to library D) last year and got a different result, but it's likely some detail was different. The dynamic linker behavior might have even changed. > | $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/liblzma.so.5 xz README > | xz: README: Unsupported options > > Well, that's not really a simulation of an application linked directly to > liblzma2 and indirectly to liblzma5... Yes, that was just the quickest way I could find to demonstrate the behavior when the symbol is taken from liblzma2. > | Unfortunately one cannot even get lucky and find the symbol from > | liblzma2 used from time to time: versioned symbols take precedence over > | unversioned ones when resolving unversioned references. > > As far as I can tell, this is not the case. Could you post your testcase somewhere? I'll do the same as well. > In debian/symbols there is: > | (symver)XZ_5.0 5.1.1alpha+20110809 > > To be pedantically correct, that should be: > | (symver)XZ_5.0 5.1.1alpha+20110809-3~ > > On the other hand, since you've just bumped SONAME, it doesn't matter at > all. You could have used even 0 here. Yes. > I am not entirely happy about your "liblzma_private_symbols" hack. It might > work well for now, but I wouldn't be surprised if it'll make your package > FTBFS with a future version of dpkg-dev, if it becomes stricter at > validating input. Well, yes, it's a hack. I watch dpkg development closely, so if I am still maintainer at the time, dpkg or the package could be adjusted appropriately to avoid fallout. Hopefully when introducing such a change, dpkg-dev would provide a more appropriate syntax for what is really intended there: <http://bugs.debian.org/630344>. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
