When trying to compile ghostscript-9.00 with the system zlib (forced by deleting the zlib folder in the ghostscript-9.00 tarball), make fails with the error message below. Note that this does not happen if --disable-compile-inits is used or if the zlib folder is not deleted from the tarball. The problem looks to be in the routine to compress the init scripts prior to compiling them into the gs binary, this should be able to use the system zlib. gcc -DHAVE_MKSTEMP -DHAVE_HYPOT -DHAVE_FILE64 -DHAVE_MKSTEMP64 -DHAVE_FONTCONFIG -DHAVE_SETLOCALE -Os -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long long" -march=i486 -mtune=i686 -pipe -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\"/usr/local/lib/ghostscript/9.00\" -I./psi -I./obj -I./obj -I./base -o ./obj/iconfig.o -c ./obj/iconfig.c make: *** No rule to make target `src/compress.c', needed by `obj/compress.o'. Stop.
Ghostscript is diretibuted with zlib. If you don't delete it before building, Ghostscript will build fine, and if you want SHARE_ZLIB=1, then the executable will use the system zlib. The fact that the build process needs (some of) the sources in the zlib we distribute does not affect the ability to build a gs that does not include the zlib objects. If you are concerned about the disk space for objects built for the %rom% file system compression (mkromfs), then you probably want to make sure and do a 'make clean' after you install the gs you built. I went back and forth between closing this as WONTFIX vs. WORKSFORME. Both apply.
Thanks - I was not comfortable that the non-system zlib was being used. Note also the the folks at blfs are also concerned about the same issue with ghostscript and system libs: http://www.linuxfromscratch.org/blfs/view/cvs/pst/gs.html
Whilst I sort of agree with Ray, unfortunately, I also feel that the capability is there in the build system, but it doesn't work. Thus I feel I should address the problem - although, for clarity, this remains an unsupported configuration.
Fixed in r12184.
NOTE: I've had to revise the changes, as the original approach broke the Windows build. You should also grab r12194 for the complete fix.
Another (hopefully final!) iteration: this time removing the requirement of using GNU make: r12199.