The patches below allow gs 8.30 to build with gcc 2.7.2.1 under SCO ODT 2.0. They should apply to other systems that support an 8 byte "long long" but do not have system headers that define the various int64 types. The patches are at ftp://ftp.newspapersystems.com/pub/ps/gs830longlong.pat I added the line define_int(f, "ARCH_LOG2_SIZEOF_LONG_LONG", ilog2(size_of(long long))); to genarch.c and then set stdint_.h to use it with # ifdef ARCH_LOG2_SIZEOF_LONG_LONG # if ARCH_SIZEOF_LONG_LONG == 8 typedef signed long long int64_t; typedef unsigned long long uint64_t; # endif # endif William http://williambader.com
Created attachment 722 [details] The patches
Your patch contains a number of extra changes. Certainly not all linux systems have stdint.h. I'm not sure that all solaris systems have the types in sys/types.h either. Does 'long long' cause compiler errors on some systems? I'm curious whether that conditional is necessary.
Aha. Supposedly we don't need 64 bit types to build; but this snuck in. Just to verify, can you give me the bit of the make output that failed, or at least the offending filenames?
Created attachment 732 [details] cc on SCO OpenServer 5.0.5 does not support long long The declaration long long n; gets "testlonglong.c", line 5: error: invalid type combination
Created attachment 733 [details] log of make showing compile failure I attached a log of a build of the original distributed gs 8.30 under SCO ODT 2.0 (a bundle with SCO Unix 3.2v4.0 and X11) using gcc 2.7.2.1, gnu ld 2.9.1, and gnu make 3.79. This gcc supports long long, but SCO cc does not, so the SCO headers do not have typedefs for int64_t. SCO cc for SCO Unix 3.2v4 and at least some versions of OpenServer 5 does not support long long. The compile for gxshade6.c fails with ./src/gxshade6.c: In function `init_patch_fill_state': ./src/gxshade6.c:165: `int64_t' undeclared (first use this function)
Ok, that's what we thought. Some of the new shading code requires the 64 bit types. Our current plan is to go head with this, but keeping in mind we may have to supply 32-bit-only versions of the calls at some point in the future for embedded systems. Folks on vendor unix can just install gcc. :-) I'll cook up better support for this in the autoconf build. Thanks for verifying the 'long long' portability issue. MSVC is another example. :)
To compile GS on OS/2 I checked out today the most recent version from CSV. I had to add -DHAVE_LONG_LONG to CCAUX=$(COMPDIR)\$(COMP) -DHAVE_LONG_LONG in os2.mak. Or is there any better solution. Without that I get the same compile errors as Comment #5.
Created attachment 875 [details] patch to genarch I needed to set HAVE_LONG_LONG to build gs 8.31 under SCO ODT 2.0 / gcc 2.7.2.1.
Re-assigning bugs which still have work to do.
Bug still reproducible in Ghostscript 9.03
Unfortunately, the patches are no longer really applicable, as we now rely on the autoconf generated configure script. If the build still doesn't with for "long long" systems, please open another bug, and we'll address it using the configure script.