[gs-devel] Fwd: ghostscript-7.20rc2: more feedback

[rillian]

On Monday, April 1, 2002 at 12:08 PM, Nelson Beebe wrote:

> 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.

We removed it from the default build on the assumption that it was 
mostly used internally. You can add it by sticking $(DD)bbox.dev in the 
DEVICES line somewhere. BTW, we're been trying to design a way to set 
the device list more easily through configure. Suggestions are welcome, 
since about all we've come up with is editing a file instead of editing 
a makefile. :)

I'd like to ask for concensus about whether this should be in the 
default build or not; seems a useful feature to me (unlike several of 
the other drivers :)

> 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?

That's where it's going. These ought to be well supported by gimp-print, 
which has an ijs interface in beta. In the meantime there's also the 
uniprint driver, which claims to support these printers and is still 
included.

> 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
> 		[etc.]
> 	 ...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
> 		[etc.]

So the try compile isn't catching that, possibly because it's issuing a 
warning rather than an error. Does the IRIX compiler error on unknown -W 
switches? Can you send me the config.log from those two builds?

>> There was one fatal compilation failure with this compiler which
>> prevented the build of gs:
>>
>> PGC-S-0032-Syntax error: Unexpected input at '/' (./src/ifapi.h: 130)

C++-style comment, fixed in CVS. I've also filed a bug requesting a test 
for this be added to our regression suite.

>> 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.

So irix seems to work out of the box. yay!

>>
>> 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.

Yes, something like that is reasonable, but not for this release. Again, 
can you investigate how the GCFLAGS test was passed with the native 
solaris compiler?

>> 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.

Quite. :-)

Thanks again for your extensive testing,
  -r