diff options
Diffstat (limited to 'winsup/bz2lib/README.COMPILATION.PROBLEMS')
| -rw-r--r-- | winsup/bz2lib/README.COMPILATION.PROBLEMS | 130 |
1 files changed, 0 insertions, 130 deletions
diff --git a/winsup/bz2lib/README.COMPILATION.PROBLEMS b/winsup/bz2lib/README.COMPILATION.PROBLEMS deleted file mode 100644 index d621ad5..0000000 --- a/winsup/bz2lib/README.COMPILATION.PROBLEMS +++ /dev/null @@ -1,130 +0,0 @@ - -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. |