diff options
Diffstat (limited to 'bzip2/README.COMPILATION.PROBLEMS')
-rw-r--r-- | bzip2/README.COMPILATION.PROBLEMS | 130 |
1 files changed, 130 insertions, 0 deletions
diff --git a/bzip2/README.COMPILATION.PROBLEMS b/bzip2/README.COMPILATION.PROBLEMS new file mode 100644 index 000000000..d621ad597 --- /dev/null +++ b/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.1 $(OBJS) + + and replacing with + + ($CC) -G -shared -o libbz2.so.1.0.1 -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. |