I tried to compile with diskn support, but the gsiodisk.c fails at line 265 (iodev_default: undeclared identifier) Also the iodev_os_fopen gives a warning : different types for formal and actual parameter 1 (i.e. the iodev_default). from gxiodev.h: /* Get the N'th IODevice. */ gx_io_device *gs_getiodevice(const gs_memory_t *,int); #define iodev_default(mem) (gs_getiodevice(mem,0)) in 8.71 this was #define iodev_default (gs_getiodevice(0))
fix at line 220 in gsiodisk.c old code: return iodev_os_fopen(iodev_default, realname, access, pfile, rfname, rnamelen); new code: return iodev_os_fopen(iodev_default(pstate->memory), realname, access, pfile, rfname, rnamelen);
This is most likely Robin's change to get rid of globals
this has also repercusions for the UFST build with COMPILE_INITS=0 fc_dafil.h: fopen(path,mode) is mapped onto sfopen(path, mode, NULL) however, sfopen in (strmio.c) now requires a valid gs_memory_t struct: pfn.iodev = iodev_default(mem); <= this should be valid. perhaps wise to use the gs_mem_ctx from the gxfapiu.c ??? in ufst/rts/fco/gs_src_strmio.h ??
Fix for the original bug committed in revision 11754 - thanks to Norbert for this. This leaves the UFST/COMPILE_INITS=0 problem. It looks to me like the neatest solution would be to change the #define at line 189 or fc_dafil.h to be a call to FAPIU_fopen, as this does exactly what we require. In order for this to work, we'd need to #include "gxfapiu.h" from within ufst (or copy the prototype of this function out into the UFST) source. I am hesitant to make such a change, so will consult with Chris first.
Talking to Chris, and updating my copy of ufst, it looks like the ufst/compile_inits=0 portion of this bug has been solved already. It appears that it was bug #691333, and that exactly the same fix I was going to apply has already been applied. Norbert: Can you confirm that you are running with the latest version of the source file please? Chris says he sent it to you in a mail on 25/5/2010 entitled "Bug 691333 - ufst build broken". If you (like me!) were using an older version on that machine then that would explain things. If you'd like a complete source dump of the latest version then please just let us know.
(In reply to comment #5) > Talking to Chris, and updating my copy of ufst, it looks like the > ufst/compile_inits=0 portion of this bug has been solved already. > > It appears that it was bug #691333, and that exactly the same fix I was going > to apply has already been applied. > > Norbert: Can you confirm that you are running with the latest version of the > source file please? Chris says he sent it to you in a mail on 25/5/2010 > entitled "Bug 691333 - ufst build broken". > > If you (like me!) were using an older version on that machine then that would > explain things. If you'd like a complete source dump of the latest version then > please just let us know. Found indeed the file, will check what went wrong on my side. Seems I didn't use it (was building with 8.71 until now, and noticed the problem 691333 in the trunk development, and forgot all about it :()
Excellent. I hereby declare this bug closed then. Thanks.