This again. I think it's a regression--it looks like a problem we fixed
last spring. If it's the same one, it's a byte order problem that occurs
on little-endian platforms like the x86. For best results on that
platform, also make sure to set _FILE_OFFSET_BITS to 64 (gcc option
"-D_FILE_OFFSET_BITS=64") or the file size will be limited (!) to 2 GB.
Randolph
A postscript to my last message...
It's not actually my declaration of lseek() "rtio.h" that's wrong; it's the fact that lseek() gets "redirected" to lseek64() in the new version of the GNU C libraries. (I swear, those guys just make my life miserable.) Here is the ever so clever declaration with -D__USE_FILE_OFFSET64 set in <unistd.h>:
extern __off64_t lseek (int __fd, __off64_t __offset, int __whence) __asm__ ("" "lseek64");
The funny __asm__ business at the end apparently causes any call to lseek() to be redirected to the function lseek64(), which is not officially part of the UNIX/C library interface.
The solution is still, as I stated, to include "platform.h" wherever lseek() is required, because I'm not about to include this sort of declaration nonsense in a Radiance header.
-Greg