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
diff --git a/lib/Support/bzip2/README.COMPILATION.PROBLEMS b/lib/Support/bzip2/README.COMPILATION.PROBLEMS
new file mode 100644
index 0000000..bd1822d
--- /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.