[Radiance-dev] Radiance compiled with mingw gcc (windows)

[Greg Ward]

> From: "Francesco Anselmo" <francesco.anselmo at arup.com>
> Date: September 12, 2005 2:11:52 PM PDT

> I've tried all of them, and they compile. What is strange is that
> if I use both -f somefile.cal and -o somefile.dat, the program
> exits nicely without writing the file, but if I remember well
> only with windows, not with linux ... strange!
> I don't think I'm doing anything wrong ...
> I will check it twice, but anyway it is not a problem, since output
> to stdout works perfectly to calculate daylight coefficients ...

The -o option should work of course, and I would like it to work.   
It's needed for other things.  If you change the line:

static void closefile(void *p) { fclose((FILE *)p); }

to:

static void closefile(void *p) { fputs("C",stderr); fclose((FILE *)p); }

You should get as many C's on your output as you have -o options.  If  
that's not happening, it means this call is not being made as it  
should be.  I'm trying it on my system now to make sure it's working  
here.

> From: Georg Mischler <schorsch at schorsch.com>
> Date: September 13, 2005 2:32:14 AM PDT
>
> Microsoft only supports long files in the low level _lseeki64(), but
> not in the stream routine(s). In the short term, -Dfseeko=fseek
> looks like a reasonable workaround.
>
> Actually, it seems that eg. recover_output() does both fseeko()
> and lseek(fileno(fp)) on the same file (the latter through
> myseeko()). Is this actually so? And if yes, what does it exactly
> mean? Can we substitute _lseeki64(fileno(fp), offset, origin) for
> fseeko(fd, offset, whence) when _FILE_OFFSET_BITS is set to 64 or
> do the two calls have different semantics?

The lseek() calls work underneath the stdio routines to get the file  
length, that's all.  It puts the pointer back to the beginning when  
it's finished, and shouldn't interfere with stdio's notion of file  
position, which fseeko() is supposed to report.  If this is broken in  
Windows, we'll have to dig out the other places I use this trick and  
find a substitute, but there's no indication it is broken as  
Francesco's problem case doesn't include the -r option, and otherwise  
recover_output() is never called.

-Greg