1 2bzip2-1.0 should compile without problems on the vast majority of 3platforms. Using the supplied Makefile, I've built and tested it 4myself for x86-linux, sparc-solaris, alpha-linux, x86-cygwin32 and 5alpha-tru64unix. With makefile.msc, Visual C++ 6.0 and nmake, you can 6build a native Win32 version too. Large file support seems to work 7correctly on at least alpha-tru64unix and x86-cygwin32 (on Windows 82000). 9 10When I say "large file" I mean a file of size 2,147,483,648 (2^31) 11bytes or above. Many older OSs can't handle files above this size, 12but many newer ones can. Large files are pretty huge -- most files 13you'll encounter are not Large Files. 14 15Earlier versions of bzip2 (0.1, 0.9.0, 0.9.5) compiled on a wide 16variety of platforms without difficulty, and I hope this version will 17continue in that tradition. However, in order to support large files, 18I've had to include the define -D_FILE_OFFSET_BITS=64 in the Makefile. 19This can cause problems. 20 21The technique of adding -D_FILE_OFFSET_BITS=64 to get large file 22support is, as far as I know, the Recommended Way to get correct large 23file support. For more details, see the Large File Support 24Specification, published by the Large File Summit, at 25 http://www.sas.com/standard/large.file/ 26 27As a general comment, if you get compilation errors which you think 28are related to large file support, try removing the above define from 29the Makefile, ie, delete the line 30 BIGFILES=-D_FILE_OFFSET_BITS=64 31from the Makefile, and do 'make clean ; make'. This will give you a 32version of bzip2 without large file support, which, for most 33applications, is probably not a problem. 34 35Alternatively, try some of the platform-specific hints listed below. 36 37You can use the spewG.c program to generate huge files to test bzip2's 38large file support, if you are feeling paranoid. Be aware though that 39any compilation problems which affect bzip2 will also affect spewG.c, 40alas. 41 42 43Known problems as of 1.0pre8: 44~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 45 46* HP/UX 10.20 and 11.00, using gcc (2.7.2.3 and 2.95.2): A large 47 number of warnings appear, including the following: 48 49 /usr/include/sys/resource.h: In function `getrlimit': 50 /usr/include/sys/resource.h:168: 51 warning: implicit declaration of function `__getrlimit64' 52 /usr/include/sys/resource.h: In function `setrlimit': 53 /usr/include/sys/resource.h:170: 54 warning: implicit declaration of function `__setrlimit64' 55 56 This would appear to be a problem with large file support, header 57 files and gcc. gcc may or may not give up at this point. If it 58 fails, you might be able to improve matters by adding 59 -D__STDC_EXT__=1 60 to the BIGFILES variable in the Makefile (ie, change its definition 61 to 62 BIGFILES=-D_FILE_OFFSET_BITS=64 -D__STDC_EXT__=1 63 64 Even if gcc does produce a binary which appears to work (ie passes 65 its self-tests), you might want to test it to see if it works properly 66 on large files. 67 68 69* HP/UX 10.20 and 11.00, using HP's cc compiler. 70 71 No specific problems for this combination, except that you'll need to 72 specify the -Ae flag, and zap the gcc-specific stuff 73 -Wall -Winline -O2 -fomit-frame-pointer -fno-strength-reduce. 74 You should retain -D_FILE_OFFSET_BITS=64 in order to get large 75 file support -- which is reported to work ok for this HP/UX + cc 76 combination. 77 78 79* SunOS 4.1.X. 80 81 Amazingly, there are still people out there using this venerable old 82 banger. I shouldn't be too rude -- I started life on SunOS, and 83 it was a pretty darn good OS, way back then. Anyway: 84 85 SunOS doesn't seem to have strerror(), so you'll have to use 86 perror(), perhaps by doing adding this (warning: UNTESTED CODE): 87 88 char* strerror ( int errnum ) 89 { 90 if (errnum < 0 || errnum >= sys_nerr) 91 return "Unknown error"; 92 else 93 return sys_errlist[errnum]; 94 } 95 96 Or you could comment out the relevant calls to strerror; they're 97 not mission-critical. Or you could upgrade to Solaris. Ha ha ha! 98 (what?? you think I've got Bad Attitude?) 99 100 101* Making a shared library on Solaris. (Not really a compilation 102 problem, but many people ask ...) 103 104 Firstly, if you have Solaris 8, either you have libbz2.so already 105 on your system, or you can install it from the Solaris CD. 106 107 Secondly, be aware that there are potential naming conflicts 108 between the .so file supplied with Solaris 8, and the .so file 109 which Makefile-libbz2_so will make. Makefile-libbz2_so creates 110 a .so which has the names which I intend to be "official" as 111 of version 1.0.0 and onwards. Unfortunately, the .so in 112 Solaris 8 appeared before I decided on the final names, so 113 the two libraries are incompatible. We have since communicated 114 and I hope that the problems will have been solved in the next 115 version of Solaris, whenever that might appear. 116 117 All that said: you might be able to get somewhere 118 by finding the line in Makefile-libbz2_so which says 119 120 $(CC) -shared -Wl,-soname -Wl,libbz2.so.1.0 -o libbz2.so.1.0.2 $(OBJS) 121 122 and replacing with 123 124 $(CC) -G -shared -o libbz2.so.1.0.2 -h libbz2.so.1.0 $(OBJS) 125 126 If gcc objects to the combination -fpic -fPIC, get rid of 127 the second one, leaving just "-fpic". 128 129 130That's the end of the currently known compilation problems. 131