home *** CD-ROM | disk | FTP | other *** search
-
- COMPILING APDF
-
-
- ** Warning **
-
- Compiling Apdf is not an easy task. It requires a good knowledge of the
- geekgadget environment. In particular, setting up an environment
- allowing to compile the PPC version can be tricky.
-
-
- With this archive and the decryption patch for xpdf-0.80 pointed to on
- the page http://www.foolabs.com/xpdf/, you can build a version of Apdf
- supporting encrypted documents.
-
- With this archive and the gzip-1.2.4 source code, you can build a
- version of Apdf with decompression handled internally. This version is a
- bit faster, especially on PPC (but don't hope too much from it).
-
- Compiling a 68k version of Apdf requires a GeekGadgets environnement
- including:
- - egcs C and C++ compilers (at least version 1.1)
- - libnix
- - amigaos includes
- - make
- - sh
- - fileutils
- and possibly a few others.
- You also need the MUI and Cybergrapics developer kits.
-
- To compile a PPC version of Apdf, you need all of the above, and
- - egcs C and C++ compilers (at least version 1.1) for PPC
- - libnixppc
- - the powerup developer kit.
-
-
-
- How to compile Apdf:
- --------------------
-
- The theory is simple: in an 'sh' shell, 'cd' to the build directory of
- your choice (buildppc, build060, ...), type 'make', wait, and if
- everything goes fine, you will get the Apdf executable in the xpdf
- subdirectory of that build directory (note: do not run 'configure' !).
- The problem is that you will probably get errors in the process.
-
-
- Some things to watch out:
-
- - some versions of libnix (and libnixppc) have a buggy atoi() function.
- To test that, check if atoi("010")==10. If not, you should replace atoi
- by a working one, e.g.:
-
- int atoi(const char* str) { return (int)strtol(str,0,10); }
-
- (While this is not necessary for Apdf, you may want to fix the atol()
- function as well.)
-
- - you will probably have to fix things in various include files.
-
-
- While a 68k executable is probably not too hard to obtain, a PPC one is
- more will require more include tweakings. Furthermore, the ppc version
- of gcc (at least the version I use) has a problem with the
- initialization of static objects. It seems that the constructors table
- built by the linker contains NULL pointers, and that the startup code
- stops executing constructors when it encounters one. To work around that
- problem, I have added a "stub.cc" file that has to be just after the
- startup code when linked, and a custom linker script that defines
- symbols for the start and the end of the ctor/dtor tables. If the
- version of gcc that you use doesn't have this problem, you *must* remove
- stub.o.
-
-
- Once you have managed to compile Apdf, building a version supporting
- encrypted documents and/or builtin decompression should be easy:
-
- The decryption patch:
-
- * Get the original decryption patch from
-
- ftp://ftp.sci.usq.edu.au/pub/linux/xpdf/xpdf-0.80-decrypt.patch
-
- * patch it to make it suitable for Apdf:
-
- patch -l <decrypt_patch.diff
-
- * apply the patch
-
- cd the_main_directory_of_the_source_archive
- patch -l -p1 <xpdf-0.80-decrypt.patch
-
- * recompile.
-
-
- The gzip patch:
-
- * get the gzip-1.2.4-src.tgz archive, e.g. from ftp://ftp.ninemoons.com
-
- * copy the unlzw.c from that archive to xpdf/unlzw.cc
-
- * apply the gzip patch:
-
- cd the_main_directory_of_the_source_archive
- patch -l -p1 <gzip.diff
-
- * recompile.
-
-
-
- SAS/C
- -----
-
- You can build a "semi-working" version of Apdf 68k using the latest
- eperimental version of the SAS/C++ compiler. It is probably easier than
- with gcc. However, the version produced by SAS/C will not properly
- behave in case a runtime error occurs, such as a memory shortage. It is
- possible that some resources are not returned to the system if such an
- error occurs. This is due to the fact that this compiler lacks
- exceptions support.
- Note that you can _not_ build a ppc version with scppc.
-
-
-