[gs-devel] ghostscript-8.31 build problems
giles at ghostscript.com
Mon Nov 1 01:46:57 PST 2004
Again, thanks for testing. Your ability to test on so many platforms
is very valuable.
> (1) The major show-stopper problem is that the jasper subtree needs
> autoconfiguration too; unfortunately, there is no
> AC_CONFIG_SUBDIRS entry for it in the top-level configure.ac. The
> result is that the jasper tree contains a generated configuration
> file jasper/src/libjasper/include/jasper/jas_config.h that just
> happens to work on GNU/Linux and two BSDs, but not on other
Is this the same as http://bugs.ghostscript.com/show_bug.cgi?id=687637 ?
If so it should also have been fixed in 8.32, where I removed the
jas_config.h that was mistakenly included with 8.31. This should cause
the Ghostscript configure to recurse and generate a correct jas_config.h.
The bug is still open because I've not done a new 'gs-specific' release
> (2) Two files contains C99/C++-style // comments:
These were corrected for 8.32.
> (4) src/gxshade6.c uses the C99 datatype int64_t. That completely
> prevents the build on IBM AIX 4.x. int64_t cannot be used without
> a configure-time provision of a fallback when it is not available.
> In general, until C99 is widely implemented and available, the
> signed and unsigned long long data types are NOT usable in
> portable software.
Yes, the new shading code assumes a 64 bit integer is available, and
unlike the color index type, no fallback is currently implemented.
Configure should discover one if it's available, and we will fix bugs
there. However, the current decision on the requirement itself is
WONTFIX without a request from a supported Artifex customer, or a
maintained patch. Is AIX 4.x the only system you have with no 64 bit
int at all?
> (3) [...]
> (5) [...]
> (7) [...]
I'll leave warnings and style issues for now.
> (6) The file jasper/src/libjasper/include/jasper/jas_types.h includes
> the C99 <stdbool.h> header file when available.
This is open as http://bugs.ghostscript.com/show_bug.cgi?id=687518
Patches and suggestions welcome.
> (8) These files contain assertions with an extra level of outer
> This caused compilation failure on several systems when they were
> expanded according to the definitions in our
I'm afraid I'm ignorant here. Can you explain for fully what's going on?
Are these magic parentheses part of the C standard? Are you just saying
that you have a broken assert.h in /usr/local/include and broken jpeg,
etc. headers in /usr/include and would like us to remove the ((x))?
What would that mean for the lines where their isn't any 'extra' pair,
like in gxshade6.c?
More information about the gs-devel