Hi Greg,
didn't know you were just about to release a new version with broadly scheduled testing.
so why not take the opportunity and actually check the setvbuf call, '#ifdef linux' if needed ?
Another subtle suggestion:
It helps to trace problems and add information about other packages, when the testers mention parameters of their Linux distribution:
the compiler version used (gcc -v)
the shared lib versions used, e.g.:
host $ ldd /usr/local/radiance/bin/rpict
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7ee7000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7db4000)
/lib/ld-linux.so.2 (0xb7f1e000)
host $ ll /lib/tls/libc.so.6
lrwxrwxrwx 1 root root 13 Feb 23 15:40 /lib/tls/libc.so.6 ->
libc-2.3.6.so
Since Radiance depends so very little on other packages, it seems useful to know what the respective distributions supply for these few libs, in extension to the distribution names.
-Peter
btw1: running 'gcc -Wall' on the rt subdirectory prints warnings of uninitialized variables. (output attached, on gcc 4.1.2) If someone want's to do a touch more, it's worth checking with the latest gcc (4.3.x) and/or Intel/AMD optimizations.
btw2: if anyone feels wants to be a pioneer during the holiday: running a debugger like valgrind on the crucial rpict and rtrace wouldn't hurt, although it does take some time to separate noise from true errors. It's worth it. anyone bothered doing this already ?
btw3: the radiance-online box, nearly celebrating one year of happy life at Berkeley, still runs Debian Linux.
e (1.97 KB)
···
--
pab-opto, Freiburg, Germany, http://www.pab-opto.de
[see web page to check digital email signature]