Summary: | diskn device fails to build | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | norbert.janssen |
Component: | PS Interpreter | Assignee: | Robin Watts <robin.watts> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | CC: | chris.liddell |
Priority: | P2 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Customer: | 661 | Word Size: | --- |
Description
norbert.janssen
2010-09-21 11:36:31 UTC
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. |