| Summary: | jmemsys.h is missing | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | kladit |
| Component: | Build Process | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
jmemsys.h is supplied as part of the libjpeg package. If you look at the beginning of sjpeg.c: /* Ghostscript uses a non-public interface to libjpeg in order to override the library's default memory manager implementation. Since many users will want to compile Ghostscript using the shared jpeg library, we provide these prototypes so that a copy of the libjpeg source distribution is not needed. The presence of the jmemsys.h header file is detected in unix-aux.mak, and written to gconfig_.h */ This would suggest to me that you have used some unusual flags when building Ghostscript. Where did you get the source you are using, and what steps did you follow to build GS ? I got the source from git of today. jmemsys.h is included in quotation marks, not as <jpeg/jmemsys.h> There are several libjpeg sources. I have installed jpeg-turbo-1.30 and with this package no jmemsys.h got installed. Sorry, not jpeg-turbo-1.30 but libjpeg-turbo-2.0.1. Also no jmemsys.h. Up to now to build ghostpdl with libjpeg-turbo linked, I removed the dir jpeg from the sources. Also the dirs libpng tiff zlib expat freetype lcms2 ijs jbig2dec to get my already installed versions used and linked. Therefore I could not found jmemsys.h in jpeg. Sorry. What is the recommended way to compile ghostpdl with libjpeg-turbo? I will try to install jmemsys.h from the sources before removing the jpeg dir as a workaround. (In reply to kladit from comment #2) > I got the source from git of today. The best thing is to quote the SHA of the Git checkout, that doesn't (or at least, shouldn't) change. The SHA1 at the time I write this is 11338176d31567a5d63e49d6f91ccac7db706716 > jmemsys.h is included in quotation marks, not as <jpeg/jmemsys.h> On my Linux system, at least, that doesn't matter. Its really to do with search order IIRC, and as I recall doesn't have any significance in this case. > There are several libjpeg sources. Well there are several numbered versions of libjpeg, but only one libjpeg project. We supply a version of libjpeg which works and builds on Linux, and which will (AIUI) be used unless you take some additional action to use a shared library. Have you supplied some additional flags when building Ghostscript ? > Sorry, not jpeg-turbo-1.30 but libjpeg-turbo-2.0.1. > Also no jmemsys.h. Its not really my area, but I don't think that the libjpeg and libjpeg-turbo packages are the same project. In fact according to the libjpeg-turbo web site, they have been independent of each other since 2010. Note the comment I pointed at in comment #1, which states we use a non-public interface to libjpeg. I very much doubt that libjpeg-turbo exposes that non-public interface. The public API of the two is (apparently) the same, but I rather doubt they copied over the non-public interfaces. I'm not the expert in the area so I'm not going to close this bug, but I believe that you must either install libjpeg, or use the version we supply (rather than a shared library build). I know we've looked at libjpeg-turbo, but I do not believe we currently support its use. (In reply to kladit from comment #4) > Up to now to build ghostpdl with libjpeg-turbo linked, I removed > the dir jpeg from the sources. > > Also the dirs libpng tiff zlib expat freetype lcms2 ijs jbig2dec to get my > already installed versions used and linked. Right, so a shared library build, I did ask. We don't recommend you build Ghostscript that way. > What is the recommended way to compile ghostpdl with libjpeg-turbo? As I said a moment ago, we don't (as far as I know) support the use of libjpeg-turbo, so if you want to use that, you're on your own. > I will try to install jmemsys.h from the sources before removing > the jpeg dir as a workaround. Again, note the comment in the source code about using a non-public interface to libjpeg, I'm *highly* doubtful that simply including the .h file is going to work. I'm not the engineer with responsibility for either builds or JPEG support, hence my caution about definitive statements, but I believe you will need to use libjpeg, either a system version or the one we supply. Ken, also I have had no problems so far with libjpeg-turbo and ghostscript I will follow your recommendation and use the built in jpeg now. Build of git SHA 11338176d31567a5d63e49d6f91ccac7db706716 failed. Can you have a look at this please? /usr/bin/cc -pipe -m64 -march=native -fPIE -pie -DHAVE_MKSTEMP -DHAVE_FILE64 -DHAVE_FSEEKO -DHAVE_MKSTEMP64 -DHAVE_FONTCONFIG -DHAVE_SETLOCALE -DHAVE_SSE2 -DHAVE_BSWAP32 -DHAVE_BYTESWAP_H -DHAVE_STRERROR -DHAVE_ISNAN -DHAVE_ISINF -DHAVE_PREAD_PWRITE=1 -DGS_RECURSIVE_MUTEXATTR=PTHREAD_MUTEX_RECURSIVE -fPIC -O2 -I/usr/local/include/tiff -I/usr/local/include/lcms2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -fno-strict-aliasing -Werror=declaration-after-statement -fno-builtin -fno-common -Werror=return-type -DHAVE_STDINT_H=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIBDL=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" -D__USE_UNIX98=1 -O2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -fstack-protector-all --param ssp-buffer-size=4 -ffat-lto-objects -Wformat -Wformat-security -Wstack-protector -I/usr/local/include/tiff -I/usr/local/include/lcms2 -DHAVE_RESTRICT=1 -DUSE_LIBICONV_GNU -I/usr/local/include/tiff -I/usr/local/include/libexpat -fno-strict-aliasing -DHAVE_POPEN_PROTO=1 -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\"/usr/lib/ghostscript/9.27\" -I./soobj -I./base -I./devices -DWHICH_CMS="lcms2mt" -L./sobin -Wl,-z,relro,-z,now -L/usr/local/lib/tiff -L/usr/local/lib/lcms2 -L/usr/X11/lib -o ./sobin/gxpsc ./soobj/realmain.o -lgxps make[3]: *** No rule to make target 'sobin/libgpdl.so.9.27', needed by 'sobin/libgpdl.so.9'. Stop. make[3]: Leaving directory '/mnt/nvme2n1p1/sources/ghostscript-9.26/ghostpdl' make[2]: *** [base/unix-dll.mak:294: so-subtarget] Error 2 make[2]: Leaving directory '/mnt/nvme2n1p1/sources/ghostscript-9.26/ghostpdl' make[1]: *** [base/unix-dll.mak:299: install-so] Error 2 make[1]: Leaving directory '/mnt/nvme2n1p1/sources/ghostscript-9.26/ghostpdl' make: *** [base/unix-dll.mak:325: soinstall] Error 2 (In reply to kladit from comment #7) > Ken, also I have had no problems so far with libjpeg-turbo and ghostscript > I will follow your recommendation and use the built in jpeg now. > > Build of git SHA 11338176d31567a5d63e49d6f91ccac7db706716 > failed. Can you have a look at this please? Well I have, literally 2 minutes ago, built from that exact SHA1 in order to investigate a different bug report, and it built perfectly well for me. As I said, I'm not the build engineer, so let me ask a dumb question; did you run autogen.sh again ? It looks like you're trying to build a so, which isn't normal, what target did you supply to make ? I may have to leave this until Monday when someone better able to help will be around. |
ghostpdl/base/jmemcust.h in line 21 includes local jmemsys.h #include "jmemsys.h" But a jmemsys.h does not exist. ./base/jmemcust.h:21:10: fatal error: jmemsys.h: No such file or directory #include "jmemsys.h" ^~~~~~~~~~~ compilation terminated.