Initial Version from bzip2 Release 1.0.2.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@18245 91177308-0d34-0410-b5e6-96231b3b80d8

15 files changed, 6297 insertions, 0 deletions

diff --git a/lib/Support/bzip2/CHANGES b/lib/Support/bzip2/CHANGES
new file mode 100644
index 0000000000..9882d971e1
--- /dev/null
+++ b/lib/Support/bzip2/CHANGES
@@ -0,0 +1,259 @@
+###############################################################################
+# LLVM CHANGES:
+#  LLVM incorporated version 1.0.2 of bzip2 and removed several files that 
+#  were deemed unnecessary. All the programs (bzip2 bzip2recover), test suites
+#  and documentaton were removed. These items are available elsewhere and
+#  LLVM does not use them.
+###############################################################################
+
+0.9.0
+~~~~~
+First version.
+
+
+0.9.0a
+~~~~~~
+Removed 'ranlib' from Makefile, since most modern Unix-es 
+don't need it, or even know about it.
+
+
+0.9.0b
+~~~~~~
+Fixed a problem with error reporting in bzip2.c.  This does not effect
+the library in any way.  Problem is: versions 0.9.0 and 0.9.0a (of the
+program proper) compress and decompress correctly, but give misleading
+error messages (internal panics) when an I/O error occurs, instead of
+reporting the problem correctly.  This shouldn't give any data loss
+(as far as I can see), but is confusing.
+
+Made the inline declarations disappear for non-GCC compilers.
+
+
+0.9.0c
+~~~~~~
+Fixed some problems in the library pertaining to some boundary cases.
+This makes the library behave more correctly in those situations.  The
+fixes apply only to features (calls and parameters) not used by
+bzip2.c, so the non-fixedness of them in previous versions has no
+effect on reliability of bzip2.c.
+
+In bzlib.c:
+   * made zero-length BZ_FLUSH work correctly in bzCompress().
+   * fixed bzWrite/bzRead to ignore zero-length requests.
+   * fixed bzread to correctly handle read requests after EOF.
+   * wrong parameter order in call to bzDecompressInit in
+     bzBuffToBuffDecompress.  Fixed.
+
+In compress.c:
+   * changed setting of nGroups in sendMTFValues() so as to 
+     do a bit better on small files.  This _does_ effect
+     bzip2.c.
+
+
+0.9.5a
+~~~~~~
+Major change: add a fallback sorting algorithm (blocksort.c)
+to give reasonable behaviour even for very repetitive inputs.
+Nuked --repetitive-best and --repetitive-fast since they are
+no longer useful.
+
+Minor changes: mostly a whole bunch of small changes/
+bugfixes in the driver (bzip2.c).  Changes pertaining to the
+user interface are:
+
+   allow decompression of symlink'd files to stdout
+   decompress/test files even without .bz2 extension
+   give more accurate error messages for I/O errors
+   when compressing/decompressing to stdout, don't catch control-C
+   read flags from BZIP2 and BZIP environment variables
+   decline to break hard links to a file unless forced with -f
+   allow -c flag even with no filenames
+   preserve file ownerships as far as possible
+   make -s -1 give the expected block size (100k)
+   add a flag -q --quiet to suppress nonessential warnings
+   stop decoding flags after --, so files beginning in - can be handled
+   resolved inconsistent naming: bzcat or bz2cat ?
+   bzip2 --help now returns 0
+
+Programming-level changes are:
+
+   fixed syntax error in GET_LL4 for Borland C++ 5.02
+   let bzBuffToBuffDecompress return BZ_DATA_ERROR{_MAGIC}
+   fix overshoot of mode-string end in bzopen_or_bzdopen
+   wrapped bzlib.h in #ifdef __cplusplus ... extern "C" { ... }
+   close file handles under all error conditions
+   added minor mods so it compiles with DJGPP out of the box
+   fixed Makefile so it doesn't give problems with BSD make
+   fix uninitialised memory reads in dlltest.c
+
+0.9.5b
+~~~~~~
+Open stdin/stdout in binary mode for DJGPP.
+
+0.9.5c
+~~~~~~
+Changed BZ_N_OVERSHOOT to be ... + 2 instead of ... + 1.  The + 1
+version could cause the sorted order to be wrong in some extremely
+obscure cases.  Also changed setting of quadrant in blocksort.c.
+
+0.9.5d
+~~~~~~
+The only functional change is to make bzlibVersion() in the library
+return the correct string.  This has no effect whatsoever on the
+functioning of the bzip2 program or library.  Added a couple of casts
+so the library compiles without warnings at level 3 in MS Visual
+Studio 6.0.  Included a Y2K statement in the file Y2K_INFO.  All other
+changes are minor documentation changes.
+
+1.0
+~~~
+Several minor bugfixes and enhancements:
+
+* Large file support.  The library uses 64-bit counters to
+  count the volume of data passing through it.  bzip2.c 
+  is now compiled with -D_FILE_OFFSET_BITS=64 to get large
+  file support from the C library.  -v correctly prints out
+  file sizes greater than 4 gigabytes.  All these changes have
+  been made without assuming a 64-bit platform or a C compiler
+  which supports 64-bit ints, so, except for the C library
+  aspect, they are fully portable.
+
+* Decompression robustness.  The library/program should be
+  robust to any corruption of compressed data, detecting and
+  handling _all_ corruption, instead of merely relying on
+  the CRCs.  What this means is that the program should 
+  never crash, given corrupted data, and the library should
+  always return BZ_DATA_ERROR.
+
+* Fixed an obscure race-condition bug only ever observed on
+  Solaris, in which, if you were very unlucky and issued
+  control-C at exactly the wrong time, both input and output
+  files would be deleted.
+
+* Don't run out of file handles on test/decompression when
+  large numbers of files have invalid magic numbers.
+
+* Avoid library namespace pollution.  Prefix all exported 
+  symbols with BZ2_.
+
+* Minor sorting enhancements from my DCC2000 paper.
+
+* Advance the version number to 1.0, so as to counteract the
+  (false-in-this-case) impression some people have that programs 
+  with version numbers less than 1.0 are in some way, experimental,
+  pre-release versions.
+
+* Create an initial Makefile-libbz2_so to build a shared library.
+  Yes, I know I should really use libtool et al ...
+
+* Make the program exit with 2 instead of 0 when decompression
+  fails due to a bad magic number (ie, an invalid bzip2 header).
+  Also exit with 1 (as the manual claims :-) whenever a diagnostic
+  message would have been printed AND the corresponding operation 
+  is aborted, for example
+     bzip2: Output file xx already exists.
+  When a diagnostic message is printed but the operation is not 
+  aborted, for example
+     bzip2: Can't guess original name for wurble -- using wurble.out
+  then the exit value 0 is returned, unless some other problem is
+  also detected.
+
+  I think it corresponds more closely to what the manual claims now.
+
+
+1.0.1
+~~~~~
+* Modified dlltest.c so it uses the new BZ2_ naming scheme.
+* Modified makefile-msc to fix minor build probs on Win2k.
+* Updated README.COMPILATION.PROBLEMS.
+
+There are no functionality changes or bug fixes relative to version
+1.0.0.  This is just a documentation update + a fix for minor Win32
+build problems.  For almost everyone, upgrading from 1.0.0 to 1.0.1 is
+utterly pointless.  Don't bother.
+
+
+1.0.2
+~~~~~
+A bug fix release, addressing various minor issues which have appeared
+in the 18 or so months since 1.0.1 was released.  Most of the fixes
+are to do with file-handling or documentation bugs.  To the best of my
+knowledge, there have been no data-loss-causing bugs reported in the
+compression/decompression engine of 1.0.0 or 1.0.1.
+
+Note that this release does not improve the rather crude build system
+for Unix platforms.  The general plan here is to autoconfiscate/
+libtoolise 1.0.2 soon after release, and release the result as 1.1.0
+or perhaps 1.2.0.  That, however, is still just a plan at this point.
+
+Here are the changes in 1.0.2.  Bug-reporters and/or patch-senders in
+parentheses.
+
+* Fix an infinite segfault loop in 1.0.1 when a directory is
+  encountered in -f (force) mode.
+     (Trond Eivind Glomsrod, Nicholas Nethercote, Volker Schmidt)
+
+* Avoid double fclose() of output file on certain I/O error paths.
+     (Solar Designer)
+
+* Don't fail with internal error 1007 when fed a long stream (> 48MB)
+  of byte 251.  Also print useful message suggesting that 1007s may be
+  caused by bad memory.
+     (noticed by Juan Pedro Vallejo, fixed by me)
+
+* Fix uninitialised variable silly bug in demo prog dlltest.c.
+     (Jorj Bauer)
+
+* Remove 512-MB limitation on recovered file size for bzip2recover
+  on selected platforms which support 64-bit ints.  At the moment
+  all GCC supported platforms, and Win32.
+     (me, Alson van der Meulen)
+
+* Hard-code header byte values, to give correct operation on platforms
+  using EBCDIC as their native character set (IBM's OS/390).
+     (Leland Lucius)
+
+* Copy file access times correctly.
+     (Marty Leisner)
+
+* Add distclean and check targets to Makefile.
+     (Michael Carmack)
+
+* Parameterise use of ar and ranlib in Makefile.  Also add $(LDFLAGS).
+     (Rich Ireland, Bo Thorsen)
+
+* Pass -p (create parent dirs as needed) to mkdir during make install.
+     (Jeremy Fusco)
+
+* Dereference symlinks when copying file permissions in -f mode.
+     (Volker Schmidt)
+
+* Majorly simplify implementation of uInt64_qrm10.
+     (Bo Lindbergh)
+
+* Check the input file still exists before deleting the output one,
+  when aborting in cleanUpAndFail().
+     (Joerg Prante, Robert Linden, Matthias Krings)
+
+Also a bunch of patches courtesy of Philippe Troin, the Debian maintainer
+of bzip2:
+
+* Wrapper scripts (with manpages): bzdiff, bzgrep, bzmore.
+
+* Spelling changes and minor enhancements in bzip2.1.
+
+* Avoid race condition between creating the output file and setting its
+  interim permissions safely, by using fopen_output_safely().
+  No changes to bzip2recover since there is no issue with file
+  permissions there.
+
+* do not print senseless report with -v when compressing an empty
+  file.
+
+* bzcat -f works on non-bzip2 files.
+
+* do not try to escape shell meta-characters on unix (the shell takes
+  care of these).
+
+* added --fast and --best aliases for -1 -9 for gzip compatibility.
+
diff --git a/lib/Support/bzip2/LICENSE b/lib/Support/bzip2/LICENSE
new file mode 100644
index 0000000000..9d4fa43790
--- /dev/null
+++ b/lib/Support/bzip2/LICENSE
@@ -0,0 +1,39 @@
+
+This program, "bzip2" and associated library "libbzip2", are
+copyright (C) 1996-2002 Julian R Seward.  All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. The origin of this software must not be misrepresented; you must 
+   not claim that you wrote the original software.  If you use this 
+   software in a product, an acknowledgment in the product 
+   documentation would be appreciated but is not required.
+
+3. Altered source versions must be plainly marked as such, and must
+   not be misrepresented as being the original software.
+
+4. The name of the author may not be used to endorse or promote 
+   products derived from this software without specific prior written 
+   permission.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
+OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
+GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Julian Seward, Cambridge, UK.
+jseward@acm.org
+bzip2/libbzip2 version 1.0.2 of 30 December 2001
+
diff --git a/lib/Support/bzip2/Makefile b/lib/Support/bzip2/Makefile
new file mode 100644
index 0000000000..8305235fe2
--- /dev/null
+++ b/lib/Support/bzip2/Makefile
@@ -0,0 +1,192 @@
+
+SHELL=/bin/sh
+
+# To assist in cross-compiling
+CC=gcc
+AR=ar
+RANLIB=ranlib
+LDFLAGS=
+
+# Suitably paranoid flags to avoid bugs in gcc-2.7
+BIGFILES=-D_FILE_OFFSET_BITS=64
+CFLAGS=-Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce $(BIGFILES)
+
+# Where you want it installed when you do 'make install'
+PREFIX=/usr
+
+
+OBJS= blocksort.o  \
+      huffman.o    \
+      crctable.o   \
+      randtable.o  \
+      compress.o   \
+      decompress.o \
+      bzlib.o
+
+all: libbz2.a bzip2 bzip2recover test
+
+bzip2: libbz2.a bzip2.o
+	$(CC) $(CFLAGS) $(LDFLAGS) -o bzip2 bzip2.o -L. -lbz2
+
+bzip2recover: bzip2recover.o
+	$(CC) $(CFLAGS) $(LDFLAGS) -o bzip2recover bzip2recover.o
+
+libbz2.a: $(OBJS)
+	rm -f libbz2.a
+	$(AR) cq libbz2.a $(OBJS)
+	@if ( test -f $(RANLIB) -o -f /usr/bin/ranlib -o \
+		-f /bin/ranlib -o -f /usr/ccs/bin/ranlib ) ; then \
+		echo $(RANLIB) libbz2.a ; \
+		$(RANLIB) libbz2.a ; \
+	fi
+
+check: test
+test: bzip2
+	@cat words1
+	./bzip2 -1  < sample1.ref > sample1.rb2
+	./bzip2 -2  < sample2.ref > sample2.rb2
+	./bzip2 -3  < sample3.ref > sample3.rb2
+	./bzip2 -d  < sample1.bz2 > sample1.tst
+	./bzip2 -d  < sample2.bz2 > sample2.tst
+	./bzip2 -ds < sample3.bz2 > sample3.tst
+	cmp sample1.bz2 sample1.rb2 
+	cmp sample2.bz2 sample2.rb2
+	cmp sample3.bz2 sample3.rb2
+	cmp sample1.tst sample1.ref
+	cmp sample2.tst sample2.ref
+	cmp sample3.tst sample3.ref
+	@cat words3
+
+install: bzip2 bzip2recover
+	if ( test ! -d $(PREFIX)/bin ) ; then mkdir -p $(PREFIX)/bin ; fi
+	if ( test ! -d $(PREFIX)/lib ) ; then mkdir -p $(PREFIX)/lib ; fi
+	if ( test ! -d $(PREFIX)/man ) ; then mkdir -p $(PREFIX)/man ; fi
+	if ( test ! -d $(PREFIX)/man/man1 ) ; then mkdir -p $(PREFIX)/man/man1 ; fi
+	if ( test ! -d $(PREFIX)/include ) ; then mkdir -p $(PREFIX)/include ; fi
+	cp -f bzip2 $(PREFIX)/bin/bzip2
+	cp -f bzip2 $(PREFIX)/bin/bunzip2
+	cp -f bzip2 $(PREFIX)/bin/bzcat
+	cp -f bzip2recover $(PREFIX)/bin/bzip2recover
+	chmod a+x $(PREFIX)/bin/bzip2
+	chmod a+x $(PREFIX)/bin/bunzip2
+	chmod a+x $(PREFIX)/bin/bzcat
+	chmod a+x $(PREFIX)/bin/bzip2recover
+	cp -f bzip2.1 $(PREFIX)/man/man1
+	chmod a+r $(PREFIX)/man/man1/bzip2.1
+	cp -f bzlib.h $(PREFIX)/include
+	chmod a+r $(PREFIX)/include/bzlib.h
+	cp -f libbz2.a $(PREFIX)/lib
+	chmod a+r $(PREFIX)/lib/libbz2.a
+	cp -f bzgrep $(PREFIX)/bin/bzgrep
+	ln $(PREFIX)/bin/bzgrep $(PREFIX)/bin/bzegrep
+	ln $(PREFIX)/bin/bzgrep $(PREFIX)/bin/bzfgrep
+	chmod a+x $(PREFIX)/bin/bzgrep
+	cp -f bzmore $(PREFIX)/bin/bzmore
+	ln $(PREFIX)/bin/bzmore $(PREFIX)/bin/bzless
+	chmod a+x $(PREFIX)/bin/bzmore
+	cp -f bzdiff $(PREFIX)/bin/bzdiff
+	ln $(PREFIX)/bin/bzdiff $(PREFIX)/bin/bzcmp
+	chmod a+x $(PREFIX)/bin/bzdiff
+	cp -f bzgrep.1 bzmore.1 bzdiff.1 $(PREFIX)/man/man1
+	chmod a+r $(PREFIX)/man/man1/bzgrep.1
+	chmod a+r $(PREFIX)/man/man1/bzmore.1
+	chmod a+r $(PREFIX)/man/man1/bzdiff.1
+	echo ".so man1/bzgrep.1" > $(PREFIX)/man/man1/bzegrep.1
+	echo ".so man1/bzgrep.1" > $(PREFIX)/man/man1/bzfgrep.1
+	echo ".so man1/bzmore.1" > $(PREFIX)/man/man1/bzless.1
+	echo ".so man1/bzdiff.1" > $(PREFIX)/man/man1/bzcmp.1
+
+distclean: clean
+clean: 
+	rm -f *.o libbz2.a bzip2 bzip2recover \
+	sample1.rb2 sample2.rb2 sample3.rb2 \
+	sample1.tst sample2.tst sample3.tst
+
+blocksort.o: blocksort.c
+	@cat words0
+	$(CC) $(CFLAGS) -c blocksort.c
+huffman.o: huffman.c
+	$(CC) $(CFLAGS) -c huffman.c
+crctable.o: crctable.c
+	$(CC) $(CFLAGS) -c crctable.c
+randtable.o: randtable.c
+	$(CC) $(CFLAGS) -c randtable.c
+compress.o: compress.c
+	$(CC) $(CFLAGS) -c compress.c
+decompress.o: decompress.c
+	$(CC) $(CFLAGS) -c decompress.c
+bzlib.o: bzlib.c
+	$(CC) $(CFLAGS) -c bzlib.c
+bzip2.o: bzip2.c
+	$(CC) $(CFLAGS) -c bzip2.c
+bzip2recover.o: bzip2recover.c
+	$(CC) $(CFLAGS) -c bzip2recover.c
+
+DISTNAME=bzip2-1.0.2
+tarfile:
+	rm -f $(DISTNAME)
+	ln -sf . $(DISTNAME)
+	tar cvf $(DISTNAME).tar \
+	   $(DISTNAME)/blocksort.c \
+	   $(DISTNAME)/huffman.c \
+	   $(DISTNAME)/crctable.c \
+	   $(DISTNAME)/randtable.c \
+	   $(DISTNAME)/compress.c \
+	   $(DISTNAME)/decompress.c \
+	   $(DISTNAME)/bzlib.c \
+	   $(DISTNAME)/bzip2.c \
+	   $(DISTNAME)/bzip2recover.c \
+	   $(DISTNAME)/bzlib.h \
+	   $(DISTNAME)/bzlib_private.h \
+	   $(DISTNAME)/Makefile \
+	   $(DISTNAME)/manual.texi \
+	   $(DISTNAME)/manual.ps \
+	   $(DISTNAME)/manual.pdf \
+	   $(DISTNAME)/LICENSE \
+	   $(DISTNAME)/bzip2.1 \
+	   $(DISTNAME)/bzip2.1.preformatted \
+	   $(DISTNAME)/bzip2.txt \
+	   $(DISTNAME)/words0 \
+	   $(DISTNAME)/words1 \
+	   $(DISTNAME)/words2 \
+	   $(DISTNAME)/words3 \
+	   $(DISTNAME)/sample1.ref \
+	   $(DISTNAME)/sample2.ref \
+	   $(DISTNAME)/sample3.ref \
+	   $(DISTNAME)/sample1.bz2 \
+	   $(DISTNAME)/sample2.bz2 \
+	   $(DISTNAME)/sample3.bz2 \
+	   $(DISTNAME)/dlltest.c \
+	   $(DISTNAME)/*.html \
+	   $(DISTNAME)/README \
+	   $(DISTNAME)/README.COMPILATION.PROBLEMS \
+	   $(DISTNAME)/CHANGES \
+	   $(DISTNAME)/libbz2.def \
+	   $(DISTNAME)/libbz2.dsp \
+	   $(DISTNAME)/dlltest.dsp \
+	   $(DISTNAME)/makefile.msc \
+	   $(DISTNAME)/Y2K_INFO \
+	   $(DISTNAME)/unzcrash.c \
+	   $(DISTNAME)/spewG.c \
+	   $(DISTNAME)/mk251.c \
+	   $(DISTNAME)/bzdiff \
+	   $(DISTNAME)/bzdiff.1 \
+	   $(DISTNAME)/bzmore \
+	   $(DISTNAME)/bzmore.1 \
+	   $(DISTNAME)/bzgrep \
+	   $(DISTNAME)/bzgrep.1 \
+	   $(DISTNAME)/Makefile-libbz2_so
+	gzip -v $(DISTNAME).tar
+
+# For rebuilding the manual from sources on my RedHat 7.2 box
+manual: manual.ps manual.pdf manual.html
+
+manual.ps: manual.texi
+	tex manual.texi
+	dvips -o manual.ps manual.dvi
+
+manual.pdf: manual.ps
+	ps2pdf manual.ps
+
+manual.html: manual.texi
+	texi2html -split_chapter manual.texi
diff --git a/lib/Support/bzip2/README b/lib/Support/bzip2/README
new file mode 100644
index 0000000000..07505d8f3d
--- /dev/null
+++ b/lib/Support/bzip2/README
@@ -0,0 +1,181 @@
+
+This is the README for bzip2, a block-sorting file compressor, version
+1.0.2.  This version is fully compatible with the previous public
+releases, versions 0.1pl2, 0.9.0, 0.9.5, 1.0.0 and 1.0.1.
+
+bzip2-1.0.2 is distributed under a BSD-style license.  For details,
+see the file LICENSE.
+
+Complete documentation is available in Postscript form (manual.ps),
+PDF (manual.pdf, amazingly enough) or html (manual_toc.html).  A
+plain-text version of the manual page is available as bzip2.txt.  
+A statement about Y2K issues is now included in the file Y2K_INFO.
+
+
+HOW TO BUILD -- UNIX
+
+Type `make'.  This builds the library libbz2.a and then the
+programs bzip2 and bzip2recover.  Six self-tests are run.
+If the self-tests complete ok, carry on to installation:
+
+To install in /usr/bin, /usr/lib, /usr/man and /usr/include, type
+   make install
+To install somewhere else, eg, /xxx/yyy/{bin,lib,man,include}, type 
+   make install PREFIX=/xxx/yyy
+If you are (justifiably) paranoid and want to see what 'make install'
+is going to do, you can first do
+   make -n install                      or
+   make -n install PREFIX=/xxx/yyy      respectively.
+The -n instructs make to show the commands it would execute, but
+not actually execute them.
+
+
+HOW TO BUILD -- UNIX, shared library libbz2.so.
+
+Do 'make -f Makefile-libbz2_so'.  This Makefile seems to work for
+Linux-ELF (RedHat 7.2 on an x86 box), with gcc.  I make no claims
+that it works for any other platform, though I suspect it probably
+will work for most platforms employing both ELF and gcc.
+
+bzip2-shared, a client of the shared library, is also built, but not
+self-tested.  So I suggest you also build using the normal Makefile,
+since that conducts a self-test.  A second reason to prefer the
+version statically linked to the library is that, on x86 platforms,
+building shared objects makes a valuable register (%ebx) unavailable
+to gcc, resulting in a slowdown of 10%-20%, at least for bzip2.
+
+Important note for people upgrading .so's from 0.9.0/0.9.5 to version
+1.0.X.  All the functions in the library have been renamed, from (eg)
+bzCompress to BZ2_bzCompress, to avoid namespace pollution.
+Unfortunately this means that the libbz2.so created by
+Makefile-libbz2_so will not work with any program which used an older
+version of the library.  Sorry.  I do encourage library clients to
+make the effort to upgrade to use version 1.0, since it is both faster
+and more robust than previous versions.
+
+
+HOW TO BUILD -- Windows 95, NT, DOS, Mac, etc.
+
+It's difficult for me to support compilation on all these platforms.
+My approach is to collect binaries for these platforms, and put them
+on the master web page (http://sources.redhat.com/bzip2).  Look there.
+However (FWIW), bzip2-1.0.X is very standard ANSI C and should compile
+unmodified with MS Visual C.  If you have difficulties building, you
+might want to read README.COMPILATION.PROBLEMS.
+
+At least using MS Visual C++ 6, you can build from the unmodified
+sources by issuing, in a command shell: 
+   nmake -f makefile.msc
+(you may need to first run the MSVC-provided script VCVARS32.BAT
+ so as to set up paths to the MSVC tools correctly).
+
+
+VALIDATION
+
+Correct operation, in the sense that a compressed file can always be
+decompressed to reproduce the original, is obviously of paramount
+importance.  To validate bzip2, I used a modified version of Mark
+Nelson's churn program.  Churn is an automated test driver which
+recursively traverses a directory structure, using bzip2 to compress
+and then decompress each file it encounters, and checking that the
+decompressed data is the same as the original.  There are more details
+in Section 4 of the user guide.
+
+
+
+Please read and be aware of the following:
+
+WARNING:
+
+   This program (attempts to) compress data by performing several
+   non-trivial transformations on it.  Unless you are 100% familiar
+   with *all* the algorithms contained herein, and with the
+   consequences of modifying them, you should NOT meddle with the
+   compression or decompression machinery.  Incorrect changes can and
+   very likely *will* lead to disastrous loss of data.
+
+
+DISCLAIMER:
+
+   I TAKE NO RESPONSIBILITY FOR ANY LOSS OF DATA ARISING FROM THE
+   USE OF THIS PROGRAM, HOWSOEVER CAUSED.
+
+   Every compression of a file implies an assumption that the
+   compressed file can be decompressed to reproduce the original.
+   Great efforts in design, coding and testing have been made to
+   ensure that this program works correctly.  However, the complexity
+   of the algorithms, and, in particular, the presence of various
+   special cases in the code which occur with very low but non-zero
+   probability make it impossible to rule out the possibility of bugs
+   remaining in the program.  DO NOT COMPRESS ANY DATA WITH THIS
+   PROGRAM UNLESS YOU ARE PREPARED TO ACCEPT THE POSSIBILITY, HOWEVER
+   SMALL, THAT THE DATA WILL NOT BE RECOVERABLE.
+
+   That is not to say this program is inherently unreliable.  Indeed,
+   I very much hope the opposite is true.  bzip2 has been carefully
+   constructed and extensively tested.
+
+
+PATENTS:
+
+   To the best of my knowledge, bzip2 does not use any patented
+   algorithms.  However, I do not have the resources available to
+   carry out a full patent search.  Therefore I cannot give any
+   guarantee of the above statement.
+
+End of legalities.
+
+
+WHAT'S NEW IN 0.9.0 (as compared to 0.1pl2) ?
+
+   * Approx 10% faster compression, 30% faster decompression
+   * -t (test mode) is a lot quicker
+   * Can decompress concatenated compressed files
+   * Programming interface, so programs can directly read/write .bz2 files
+   * Less restrictive (BSD-style) licensing
+   * Flag handling more compatible with GNU gzip
+   * Much more documentation, i.e., a proper user manual
+   * Hopefully, improved portability (at least of the library)
+
+WHAT'S NEW IN 0.9.5 ?
+
+   * Compression speed is much less sensitive to the input
+     data than in previous versions.  Specifically, the very
+     slow performance caused by repetitive data is fixed.
+   * Many small improvements in file and flag handling.
+   * A Y2K statement.
+
+WHAT'S NEW IN 1.0.0 ?
+
+   See the CHANGES file.
+
+WHAT'S NEW IN 1.0.2 ?
+
+   See the CHANGES file.
+
+
+I hope you find bzip2 useful.  Feel free to contact me at
+   jseward@acm.org
+if you have any suggestions or queries.  Many people mailed me with
+comments, suggestions and patches after the releases of bzip-0.15,
+bzip-0.21, and bzip2 versions 0.1pl2, 0.9.0, 0.9.5, 1.0.0 and 1.0.1,
+and the changes in bzip2 are largely a result of this feedback.
+I thank you for your comments.
+
+At least for the time being, bzip2's "home" is (or can be reached via)
+http://sources.redhat.com/bzip2.
+
+Julian Seward
+jseward@acm.org
+
+Cambridge, UK (and what a great town this is!)
+
+18     July 1996 (version 0.15)
+25   August 1996 (version 0.21)
+ 7   August 1997 (bzip2, version 0.1)
+29   August 1997 (bzip2, version 0.1pl2)
+23   August 1998 (bzip2, version 0.9.0)
+ 8     June 1999 (bzip2, version 0.9.5)
+ 4     Sept 1999 (bzip2, version 0.9.5d)
+ 5      May 2000 (bzip2, version 1.0pre8)
+30 December 2001 (bzip2, version 1.0.2pre1)
\ No newline at end of file
diff --git a/lib/Support/bzip2/README.COMPILATION.PROBLEMS b/lib/Support/bzip2/README.COMPILATION.PROBLEMS
new file mode 100644
index 0000000000..bd1822dffb
--- /dev/null
+++ b/lib/Support/bzip2/README.COMPILATION.PROBLEMS
@@ -0,0 +1,130 @@
+
+bzip2-1.0 should compile without problems on the vast majority of
+platforms.  Using the supplied Makefile, I've built and tested it
+myself for x86-linux, sparc-solaris, alpha-linux, x86-cygwin32 and
+alpha-tru64unix.  With makefile.msc, Visual C++ 6.0 and nmake, you can
+build a native Win32 version too.  Large file support seems to work
+correctly on at least alpha-tru64unix and x86-cygwin32 (on Windows
+2000).
+
+When I say "large file" I mean a file of size 2,147,483,648 (2^31)
+bytes or above.  Many older OSs can't handle files above this size,
+but many newer ones can.  Large files are pretty huge -- most files
+you'll encounter are not Large Files.
+
+Earlier versions of bzip2 (0.1, 0.9.0, 0.9.5) compiled on a wide
+variety of platforms without difficulty, and I hope this version will
+continue in that tradition.  However, in order to support large files,
+I've had to include the define -D_FILE_OFFSET_BITS=64 in the Makefile.
+This can cause problems.
+
+The technique of adding -D_FILE_OFFSET_BITS=64 to get large file
+support is, as far as I know, the Recommended Way to get correct large
+file support.  For more details, see the Large File Support
+Specification, published by the Large File Summit, at
+   http://www.sas.com/standard/large.file/
+
+As a general comment, if you get compilation errors which you think
+are related to large file support, try removing the above define from
+the Makefile, ie, delete the line
+   BIGFILES=-D_FILE_OFFSET_BITS=64 
+from the Makefile, and do 'make clean ; make'.  This will give you a
+version of bzip2 without large file support, which, for most
+applications, is probably not a problem.  
+
+Alternatively, try some of the platform-specific hints listed below.
+
+You can use the spewG.c program to generate huge files to test bzip2's
+large file support, if you are feeling paranoid.  Be aware though that
+any compilation problems which affect bzip2 will also affect spewG.c,
+alas.
+
+
+Known problems as of 1.0pre8:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+* HP/UX 10.20 and 11.00, using gcc (2.7.2.3 and 2.95.2):  A large
+  number of warnings appear, including the following:
+
+     /usr/include/sys/resource.h: In function `getrlimit':
+     /usr/include/sys/resource.h:168: 
+        warning: implicit declaration of function `__getrlimit64'
+     /usr/include/sys/resource.h: In function `setrlimit':
+     /usr/include/sys/resource.h:170: 
+        warning: implicit declaration of function `__setrlimit64'
+
+  This would appear to be a problem with large file support, header
+  files and gcc.  gcc may or may not give up at this point.  If it
+  fails, you might be able to improve matters by adding 
+     -D__STDC_EXT__=1
+  to the BIGFILES variable in the Makefile (ie, change its definition
+  to
+     BIGFILES=-D_FILE_OFFSET_BITS=64 -D__STDC_EXT__=1
+
+  Even if gcc does produce a binary which appears to work (ie passes
+  its self-tests), you might want to test it to see if it works properly
+  on large files.
+
+
+* HP/UX 10.20 and 11.00, using HP's cc compiler.
+
+  No specific problems for this combination, except that you'll need to
+  specify the -Ae flag, and zap the gcc-specific stuff
+  -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce.
+  You should retain -D_FILE_OFFSET_BITS=64 in order to get large
+  file support -- which is reported to work ok for this HP/UX + cc
+  combination.
+
+
+* SunOS 4.1.X.
+
+  Amazingly, there are still people out there using this venerable old
+  banger.  I shouldn't be too rude -- I started life on SunOS, and
+  it was a pretty darn good OS, way back then.  Anyway:
+
+     SunOS doesn't seem to have strerror(), so you'll have to use
+     perror(), perhaps by doing adding this (warning: UNTESTED CODE):
+
+     char* strerror ( int errnum )
+     {
+        if (errnum < 0 || errnum >= sys_nerr)
+           return "Unknown error"; 
+        else
+           return sys_errlist[errnum];
+     }
+
+   Or you could comment out the relevant calls to strerror; they're
+   not mission-critical.  Or you could upgrade to Solaris.  Ha ha ha!
+   (what??  you think I've got Bad Attitude?) 
+
+
+* Making a shared library on Solaris.  (Not really a compilation
+  problem, but many people ask ...)  
+
+  Firstly, if you have Solaris 8, either you have libbz2.so already
+  on your system, or you can install it from the Solaris CD.  
+
+  Secondly, be aware that there are potential naming conflicts
+  between the .so file supplied with Solaris 8, and the .so file
+  which Makefile-libbz2_so will make.  Makefile-libbz2_so creates
+  a .so which has the names which I intend to be "official" as
+  of version 1.0.0 and onwards.  Unfortunately, the .so in
+  Solaris 8 appeared before I decided on the final names, so
+  the two libraries are incompatible.  We have since communicated
+  and I hope that the problems will have been solved in the next
+  version of Solaris, whenever that might appear.
+
+  All that said: you might be able to get somewhere
+  by finding the line in Makefile-libbz2_so which says
+
+  $(CC) -shared -Wl,-soname -Wl,libbz2.so.1.0 -o libbz2.so.1.0.2 $(OBJS)
+
+  and replacing with 
+
+  $(CC) -G -shared -o libbz2.so.1.0.2 -h libbz2.so.1.0 $(OBJS)
+  
+  If gcc objects to the combination -fpic -fPIC, get rid of
+  the second one, leaving just "-fpic".
+
+
+That's the end of the currently known compilation problems.
diff --git a/lib/Support/bzip2/Y2K_INFO b/lib/Support/bzip2/Y2K_INFO
new file mode 100644
index 0000000000..55fd56a2ed
--- /dev/null
+++ b/lib/Support/bzip2/Y2K_INFO
@@ -0,0 +1,34 @@
+
+Y2K status of bzip2 and libbzip2, versions 0.1, 0.9.0 and 0.9.5
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Informally speaking:
+   bzip2 is a compression program built on top of libbzip2, 
+   a library which does the real work of compression and 
+   decompression.  As far as I am aware, libbzip2 does not have 
+   any date-related code at all.
+
+   bzip2 itself copies dates from source to destination files 
+   when compressing or decompressing, using the 'stat' and 'utime' 
+   UNIX system calls.  It doesn't examine, manipulate or store the 
+   dates in any way.  So as far as I can see, there shouldn't be any 
+   problem with bzip2 providing 'stat' and 'utime' work correctly 
+   on your system.
+
+   On non-unix platforms (those for which BZ_UNIX in bzip2.c is
+   not set to 1), bzip2 doesn't even do the date copying.
+
+   Overall, informally speaking, I don't think bzip2 or libbzip2 
+   have a Y2K problem.
+
+Formally speaking:
+   I am not prepared to offer you any assurance whatsoever 
+   regarding Y2K issues in my software.  You alone assume the 
+   entire risk of using the software.  The disclaimer of liability 
+   in the LICENSE file in the bzip2 source distribution continues 
+   to apply on this issue as with every other issue pertaining 
+   to the software.
+
+Julian Seward