Package: xz-utils / 5.2.2-1.2
Metadata
Package | Version | Patches format |
---|---|---|
xz-utils | 5.2.2-1.2 | 3.0 (quilt) |
Patch series
view the series filePatch | File delta | Description |
---|---|---|
liblzma skip ABI incompatible check when liblzma.so.patch | (download) |
configure.ac |
5 5 + 0 - 0 ! |
liblzma: skip abi-incompatible check when liblzma.so.2 is loaded MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When liblzma started using ELF symbol versioning at the same time as a soname bump (2 5) and a small increase in the reserved space at the end of the lzma_stream structure checked by lzma_code, introducing an unversioned compatibility symbol to ease the transition seemed like a great idea. After all: - most applications only use one version of the library (liblzma.so.2 or liblzma.so.5) and would obviously work fine - applications linking to the new version of the library (liblzma.so.5) should use the default, versioned lzma_code symbol so errors initializing the reserved space can be noticed - symbol versioning should ensure application/library mixtures independently making use of both versions of the library also work. Calls using the unversioned symbol names would be resolved using the old symbol from liblzma.so.2 or the compatibility symbol from liblzma.so.5, avoiding segfaults and spurious LZMA_OPTIONS_ERROR errors. - application/library mixtures using both versions of the library and passing lzma_stream objects between the two would break, but that was never supposed to be supported, anyway. Three toolchain bugs dash that plan. Current (2.22) versions of the gold linker cannot be used to build libraries providing versioned and unversioned symbols with the same name. On the other hand, BFD ld doesn't mind. So GNU gold refuses to link versions of liblzma including the compatibility symbol (PR12261): /usr/bin/ld: error: symbol lzma_code has undefined version Annoying, but livable. liblzma with the compatibility symbol just has to be built with BFD ld. More importantly, gold does not support linking to libraries providing versioned and unversioned symbols with the same name. If I link some code to a version of liblzma with the compatibility symbol: ld -o demo demo.o -llzma then the documented behavior, implemented by BFD ld, is to interpret calls to lzma_code as referring to the default version (lzma_code@XZ_5.0). Current versions of GNU gold treat such calls as referring to whichever symbol comes first in liblzma.so.5's symbol table. If the unversioned symbol comes first (and in Debian liblzma5 5.1.1alpha+20110809-3 it does), GNU gold will mislink new applications to use the unversioned compatibility symbol (PR13521): $ ld.gold -o test.gold test.o -llzma $ eu-readelf -s test.gold | grep lzma_code 1: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF lzma_code 5: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF lzma_code There is no warning. Worse, ld.so from glibc unpredictably will sometimes use the versioned symbol to resolve references to the unversioned base version when both are present (PR12977). Clearly no one has been testing mixtures of versioned and unversioned symbols at all, and we cannot trust the symbol resolution process to do anything in particular for them. This patch implements an alternative method to implement the same compatibility goals described above. - No more compatibility symbol. liblzma.so.5 will define lzma_code only once, with version XZ_5.0. - When initializing an lzma_stream object, use dlopen("liblzma.so.2", RTLD_NOLOAD) to detect whether the caller might have been expecting the old ABI, and store that information in the private stream->internal->liblzma2_compat field. - In lzma_code, when checking reserved fields, skip fields past the old end of the lzma_stream structure ifying reserved fields if and only if this->internal->liblzma2_compat is false. That's it. Hopefully this time it will work reliably. Thanks to Eduard Bloch for noticing PR13521 and to Ian Lance Taylor for PR12977. Patch-Name: liblzma-skip-ABI-incompatible-check-when-liblzma.so.patch Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> |
liblzma make dlopen based liblzma2 compatibility opt.patch | (download) |
configure.ac |
33 31 + 2 - 0 ! |
liblzma: make dlopen()-based liblzma2 compatibility optional MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Suppose I want to build a statically linked program: gcc -static -o app app.c -lrpm -llzma Suppose further that librpm.a was built against a pre-5.0 version of liblzma so it does not allocate as much space for reserved fields at the end of lzma_stream as the current API requires. (This is a hypothetical scenario |
kfreebsd link against libfreebsd glue.patch | (download) |
configure.ac |
7 7 + 0 - 0 ! |
kfreebsd: link against libfreebsd-glue cpuset_getaffinity() is available on kfreebsd but not in libc but in libfreebsd-glue. This code adds the library if kfreebsd is detected so cpuset_getaffinity() can be used. Without it tuklib_cpucores will detect `cpuset' because the compile test succeeds and later it fails at link phase. Patch-Name: kfreebsd-link-against-libfreebsd-glue.patch Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> |