mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-11-01 00:11:00 +00:00
26eda77f1f
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@18245 91177308-0d34-0410-b5e6-96231b3b80d8
131 lines
5.2 KiB
Plaintext
131 lines
5.2 KiB
Plaintext
|
|
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.
|