| |
| 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. |