[Radiance-dev] Help compiling 3R9 for Linux

Gregory J. Ward gregoryjward at gmail.com
Thu May 1 08:58:36 PDT 2008


Hi Peter,

Thanks for your suggestions.  Sorry about not including the setvbuf()  
call in the release -- I was kind of hoping you'd run the timings for  
me, since you're the one with the giant octrees.  I am a little wary  
of this call, since it has given me grief in the past.  From my  
perspective, it's up to the system to decide how large i/o buffers  
should be for peak efficiency.  My prediction in this case is the  
time involved in the other parts of reading octrees and meshes will  
overshadow the system read times, even on NFS.

I took a look at the warnings, and got about halfway through the  
"possible unintialized variable" cases without spotting anything  
wrong, so I gave up.  If you want to go in and initialize these  
variables to quiet the warnings, be my guest.  The only thing I ask  
is that you initialize them to an illegal value that will cause a  
runtime error, because I'd want to know if they really weren't being  
set properly, and leaving them uninitialized is my usual method  
(since they just get whatever random data is on the stack in most  
systems).  For me, fixing the warnings makes debugging more difficult  
rather than easier.  I did fix a couple of the other warnings,  
though.  Thanks for sending them.

Regarding your btw3, I did think of compiling on radiance-online, but  
I wasn't sure how to get a good, portable set of binaries out of it.   
I don't really know what I'm doing on Linux.

Cheers,
-Greg

> From: Peter Apian-Bennewitz <apian at pab-opto.de>
> Date: May 1, 2008 12:50:36 AM PDT
>
> 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.



More information about the Radiance-dev mailing list