Re: RFS: xz-utils (updated package)
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>.
Reply to: