configure.ac | 1 0 + 1 - 0 !
src/liblzma/Makefile.am | 2 1 + 1 - 0 !
src/liblzma/api/lzma/container.h | 167 0 + 167 - 0 !
src/liblzma/api/lzma/version.h | 2 1 + 1 - 0 !
src/liblzma/common/Makefile.inc | 7 0 + 7 - 0 !
src/liblzma/common/common.c | 9 1 + 8 - 0 !
src/liblzma/common/common.h | 16 0 + 16 - 0 !
src/liblzma/common/outqueue.c | 184 0 + 184 - 0 !
src/liblzma/common/outqueue.h | 155 0 + 155 - 0 !
src/liblzma/common/stream_encoder_mt.c | 1013 0 + 1013 - 0 !
src/xz/args.c | 5 2 + 3 - 0 !
src/xz/coder.c | 210 81 + 129 - 0 !
src/xz/hardware.c | 24 12 + 12 - 0 !
src/xz/hardware.h | 9 5 + 4 - 0 !
src/xz/private.h | 2 0 + 2 - 0 !
src/xz/xz.1 | 34 14 + 20 - 0 !
16 files changed, 117 insertions(+), 1723 deletions(-)

 remove threading functionality for now

This reverts the following commits:

 - 6ef4eabc0 (Bump the version number to 5.1.1alpha and liblzma soname
   to 5.0.99)
 - 70e750f59 (xz: Update the man page about threading)
 - c29e6630c (xz: Print the maximum number of worker threads in xz -vv)
 - 335fe260a (xz: Minor internal changes to handling of --threads)
 - 24e0406c0 (xz: Add support for threaded compression)
 - 9a4377be0 (Put the unstable APIs behind #ifdef LZMA_UNSTABLE)
 - de678e0c9 (liblmza: Add lzma_stream_encoder_mt() for threaded
   compression)

The multithreaded compression functions, while useful, are not set in
stone as part of the stable ABI.  Changes will be easier to weather
until the functions stabilize if they are left out from the
non-experimental development branch of Debian for now.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

src/liblzma/liblzma.map | 8 1 + 7 - 0 !
1 file changed, 1 insertion(+), 7 deletions(-)

 liblzma: remove xz_5.1.1alpha version symbol

Now that the lzma_stream_encoder_mt{,_memusage} symbols are gone on
this branch, liblzma should stop pretending to satisfy dependencies on
XZ_5.1.1alpha.

After this change, programs relying on those symbols will error out
immediately at startup like they are supposed to:

	app: liblzma.so.5: version `XZ_5.1.1alpha' not found (required by app)

And your scripts that look for version definition entries with
readelf -s (like RPMs find-provides) can tell that this copy of
liblzma lacks support for multithreaded encoding.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

configure.ac | 5 5 + 0 - 0 !
src/liblzma/common/common.c | 40 38 + 2 - 0 !
src/liblzma/common/common.h | 4 4 + 0 - 0 !
3 files changed, 47 insertions(+), 2 deletions(-)

 liblzma: skip abi-incompatible check when liblzma.so.2 is loaded

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.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

configure.ac | 33 31 + 2 - 0 !
src/liblzma/common/common.c | 40 35 + 5 - 0 !
src/liblzma/common/common.h | 2 2 + 0 - 0 !
3 files changed, 68 insertions(+), 7 deletions(-)

 liblzma: make dlopen()-based liblzma2 compatibility optional

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 

src/xz/xz.1 | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 xz: update man page date to match the latest update.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

src/xz/xz.1 | 18 17 + 1 - 0 !
1 file changed, 17 insertions(+), 1 deletion(-)

 xz: update the man page about the new field in --robot -lvv.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

src/xz/list.c | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 xz: fix the version number printed by xz -lvv.

The decoder bug was fixed in 5.0.2 instead of 5.0.3.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

src/liblzma/lzma/lzma_decoder.c | 8 6 + 2 - 0 !
src/liblzma/rangecoder/range_decoder.h | 12 9 + 3 - 0 !
2 files changed, 15 insertions(+), 5 deletions(-)

 liblzma: check that the first byte of range encoded data is 0x00.

It is just to be more pedantic and thus perhaps catch broken
files slightly earlier.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>