[gs-devel] Fwd: ghostscript-7.20rc2: more feedback
rillian
rillian at telus.net
Mon Apr 1 12:32:09 PST 2002
Nelson, I'm forwarding your response to gs-devel. That's a more
appropriate forum for discussing these issues. If there's some reason
you prefer private email, just let me know.
-r
Begin forwarded message:
> From: "Nelson H. F. Beebe" <beebe at math.utah.edu>
> Date: Mon Apr 01, 2002 12:08:14 PM America/Vancouver
> To: rillian <rillian at telus.net>
> Cc: beebe at math.utah.edu
> Subject: Re: ghostscript-7.20rc2: more feedback
>
> [If you'd like me to cc bug-gs at ghostscript.com on these reports, let
> me know: otherwise, I'm trying to keep the list traffic uncluttered.
> Also, let me know if you'd like one report per build system, rather
> than a digest of several builds, like this message has.]
>
> Issues that I raised with ghostscript-7.20rc1 that are still not
> addressed:
>
> (1) getting LDFLAGS into obj/ldt.tr so that the bin/gs file can get
> the proper paths to shared libraries recorded, eliminating the
> need for LD_LIBRARY_PATH settings for all gs users.
>
> (2) version number on installed gs, with symlink from gs-x.yz to
> $(prefix)/gs
>
> (3) some systems need -I$(prefix)/include to find header files
> (e.g. zlib.h)
>
> (4) no check target
>
> I ran a comparison of the output of "gs --help" for version 7.00,
> which I built with the customized pre-autoconf Makefile,
> src/all-arch.mak, versus similar output from gs-7.20rc2, and found
> that under gs-7.00, which had no additional devices specified for the
> build, I got three devices that are absent in gs-7.20rc2:
>
> bbox st800 stcolor
>
> Examination of the doc/*.html files suggests that st800 and stcolor
> might now be subsumed under the dynamic inkjet support in the ijs
> device. Is that the case?
>
> The bbox device is one that Peter Deutsch added a few years ago at my
> request, and is a critical one that we use a great deal for computing
> exact bounding boxes of PostScript figures that are included as images
> in typeset documents from, e.g., TeX and troff.
>
> My builds of ghostscript-7.20rc1 with native C compilers were partly
> successful, but there are still some gcc'isms remaining:
>
> Portland group compilers:
>
> % env CC=pgcc CXX=pgCC LDFLAGS="-R$prefix/lib -L$prefix/lib"
> ./configure
> checking for gcc... pgcc
> ...
> checking whether we are using the GNU C compiler... no
> ...
> checking supported compiler flags...
> -Wall
> -Wstrict-prototypes
> -Wmissing-declarations
> -Wmissing-prototypes
> -Wcast-qual
> -Wwrite-strings
> -fno-builtin
> -fno-common
> ...done.
>
> % pgcc -DHAVE_MKSTEMP -O2 -Wall -Wstrict-prototypes
> -Wmissing-declarations -Wmissing-prototypes -Wcast-qual -Wwrite-strings
> -fno-builtin -fno-common -I./obj -I./src -o ./obj/gp_getnv.o -c
> ./src/gp_getnv.c
> pgcc-Warning-Unknown switch: -Wall
> pgcc-Warning-Unknown switch: -Wstrict-prototypes
> pgcc-Warning-Unknown switch: -Wmissing-declarations
> pgcc-Warning-Unknown switch: -Wmissing-prototypes
> pgcc-Warning-Unknown switch: -Wcast-qual
> pgcc-Warning-Unknown switch: -Wwrite-strings
> pgcc-Warning-Unknown switch: -fno-builtin
> pgcc-Warning-Unknown switch: -fno-common
>
> [These warnings got repeated for every source file.]
>
> There was one fatal compilation failure with this compiler which
> prevented the build of gs:
>
> % pgcc -DHAVE_MKSTEMP -O2 -Wall -Wstrict-prototypes
> -Wmissing-declarations -Wmissing-prototypes -Wcast-qual -Wwrite-strings
> -fno-builtin -fno-common -I./src -I./obj -I./obj -I./src -o
> ./obj/zfapi.o -c ./src/zfapi.c
> PGC-S-0032-Syntax error: Unexpected input at '/' (./src/ifapi.h: 130)
> PGC-S-0029-Syntax error: Recovery attempted by deleting from '/'
> on line 130 through '/' on line 130 (./src/ifapi.h)
> PGC/x86 Linux/x86 3.3-1: compilation completed with severe errors
>
> The build on SGI IRIX 6.5 with native cc did not get the unwanted gcc
> flags like the Portland Group pgcc did. The build completed without
> errors, and the resulting executable displays my usual tiger.ps file
> test just fine.
>
> The build on Compaq/DEC Alpha OSF/1 4.0 with native "cc -ieee" got one
> compilation failure:
>
> % cc -ieee -I/usr/local/include -DHAVE_MKSTEMP -O2 -fno-builtin
> -fno-common -I./obj -I./src -Isrc -DSHARE_ZLIB=1 -o ./obj/szlibc.o -c
> ./src/szlibc.c
> cc: Error: ./src/szlibc.c, line 32: In this declaration, the type
> of "st_zlib_state" is not compatible with the type of a previous
> declaration of "st_zlib_state" at line number 45 in file
> ./src/szlibx.h. (notcompat)
> public_st_zlib_state();
> ^
> make: *** [obj/szlibc.o] Error 1
>
> This compiler is picky about the use of const, which is not used
> consistently in this case, as illustrated by grepping the preprocessor
> output for st_zlib_state:
>
> % cc -ieee -I/usr/local/include -DHAVE_MKSTEMP -O2 -fno-builtin
> -fno-common -I./obj -I./src -Isrc -DSHARE_ZLIB=1 -o ./obj/szlibc.o -E
> ./src/szlibc.c | grep st_zlib_state
> extern const gs_memory_struct_type_t st_zlib_state;
> static gc_ptr_element_t zlib_state_enum_ptrs[] = { { GC_ELT_OBJ,
> ((int) ( (char *)&((stream_zlib_state *)0)->dynamic - (char
> *)((stream_zlib_state *)0) )) } }; static gc_struct_data_t
> zlib_state_reloc_ptrs = { (sizeof(zlib_state_enum_ptrs) /
> sizeof((zlib_state_enum_ptrs)[0])), 0, 0, zlib_state_enum_ptrs };
> gs_memory_struct_type_t st_zlib_state = { sizeof(stream_zlib_state),
> "zlibEncode/Decode state", 0, 0, basic_enum_ptrs, basic_reloc_ptrs, 0,
> &zlib_state_reloc_ptrs };
>
> Interestingly, the Compaq OSF/1 5.0 cc compiler did not reject that
> file, and the build was successful there, and the tiger.ps file
> displays without problem.
>
> On IBM AIX 4.3 with gcc, compilation fails because the conflicting
> typedef reported earlier:
>
> % gcc -I/uufs/inscc.utah.edu/common/home/mthnhb/ppc/local/include
> -DHAVE_MKSTEMP -O2 -Wall -Wstrict-prototypes -Wmissing-declarations
> -Wmissing-prototypes -Wcast-qual -Wwrite-strings -fno-builtin
> -fno-common -Iicclib -I./src -I./obj -o ./obj/icc.o -c icclib/icc.c
> icclib/icc.c:9625: warning: `/*' within comment
> In file included from icclib/icc.c:142:
> icclib/icc.h:187: conflicting types for `int64'
> /usr/include/sys/inttypes.h:629: previous declaration of `int64'
> ....
>
> I'll report later on the AIX 4.3 native compiler build test, which is
> still underway.
>
> The Sun Solaris 2.8 native cc build produced warnings about these
> Makefile setting:
>
> CFLAGS_STANDARD=-O2
> CFLAGS_PROFILE=-pg -O2
> GCFLAGS= -fno-builtin -fno-common
>
> The Sun compilers for C, C++, Fortran 77, Fortran 90, and Fortran 95
> all require that -O2 be called -xO2, I think for POSIX conformance.
> In general, one cannot expect -On (n a digit string) to be portable,
> and thus, it should be simplified to -O. For user convenience, I
> generally code my Makefiles with optimization levels provided by a
> separate option, since CFLAGS often has a lot of other stuff. For
> example,
>
> CFLAGS = $(INCLUDES) $(DEFINES) $(OPT)
> DEFINES = -Dx=y -Dz=zz ...
> INCLUDES = -Iinclude -I$(prefix)/include
> OPT = -O
>
> This allows the user to do
>
> make OPT='-xO5 -inline -dalign -libmil'
>
> without having to repeat the other CFLAGS settings.
>
> I had to override GCFLAGS completely, since it is gcc-specific:
>
> make CC="c89 -I/usr/local/include" CFLAGS_STANDARD=-xO2 GCFLAGS=
>
> With that command, I got a successful Sun Solaris 2.8 build of
> gs-7.20rc that displays tiger.ps correctly.
>
> There are quite a few compiler warnings, several potentially serious,
> reported across my 25 build attempts today; I can summarize them once
> we get the build problems out of the way. Trying to deal with them
> now might swamp the gs developers.
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe Tel: +1 801 581
> 5254 -
> - Center for Scientific Computing FAX: +1 801 585 1640, +1 801
> 581 4148 -
> - University of Utah Internet e-mail:
> beebe at math.utah.edu -
> - Department of Mathematics, 110 LCB beebe at acm.org
> beebe at computer.org -
> - 155 S 1400 E RM 233
> beebe at ieee.org -
> - Salt Lake City, UT 84112-0090, USA URL:
> http://www.math.utah.edu/~beebe -
> -------------------------------------------------------------------------------
>
More information about the gs-devel
mailing list