Compiling 3.6alpha on cutting-edge Linux

Debian sid (unstable) version, gcc-3.3. I used scads of Pentium-4 compiler options, but I can't look them up now--the system I was testing on is running MS-Windows at the moment.

I noted these problems:

1. There are two places where strcpy() is declared as an external function; unfortunately it's a macro in that environment, and one gets a confusing compile-time error. PJ Plauger says that use of macros in this way is valid, at least as of C99. See <http://www.dinkumware.com/manuals/reader.aspx?b=c/&h=lib_over.html>.

2. The provided version of libtiff does not compile in that environment; the configure script fails. I suspect a conflict with the system's version of "bash," which may have a bug--it is "unstable," after all. The current version of libtiff compiles, but I did not test its functionality. Libtiff is actually available on that platform as the Debian package libtiffg3.

3. That version of Linux supports OpenGL, but I had to hack makeall to get it built in.

"rholo" sure was fast, though!

Randolph

From: Randolph Fritz <[email protected]>
Date: Wed May 14, 2003 9:07:46 PM US/Pacific
To: [email protected]
Subject: [Radiance-dev] Compiling 3.6alpha on cutting-edge Linux
Reply-To: [email protected]

Debian sid (unstable) version, gcc-3.3. I used scads of Pentium-4 compiler options, but I can't look them up now--the system I was testing on is running MS-Windows at the moment.

I noted these problems:

1. There are two places where strcpy() is declared as an external function; unfortunately it's a macro in that environment, and one gets a confusing compile-time error. PJ Plauger says that use of macros in this way is valid, at least as of C99. See <http://www.dinkumware.com/manuals/reader.aspx?b=c/&h=lib_over.html>.

Can you tell me where you found these? I removed all the ones I could find, and you could save me some tedious searching if you know where they are.

2. The provided version of libtiff does not compile in that environment; the configure script fails. I suspect a conflict with the system's version of "bash," which may have a bug--it is "unstable," after all. The current version of libtiff compiles, but I did not test its functionality. Libtiff is actually available on that platform as the Debian package libtiffg3.

I don't know enough abot libtiff's build process to hack it. There are some problems on Solaris as well.

3. That version of Linux supports OpenGL, but I had to hack makeall to get it built in.

You can add "ogl" to the SPECIAL= line of rmake -- you don't need to hack makeall, really.

-Greg

From: Randolph Fritz <[email protected]>
Date: Wed May 14, 2003 9:07:46 PM US/Pacific
To: [email protected]
Subject: [Radiance-dev] Compiling 3.6alpha on cutting-edge Linux
Reply-To: [email protected]

Debian sid (unstable) version, gcc-3.3. I used scads of Pentium-4 compiler options, but I can't look them up now--the system I was testing on is running MS-Windows at the moment.

I noted these problems:

1. There are two places where strcpy() is declared as an external function; unfortunately it's a macro in that environment, and one gets a confusing compile-time error. PJ Plauger says that use of macros in this way is valid, at least as of C99. See <http://www.dinkumware.com/manuals/reader.aspx?b=c/&h=lib_over.html>.

Can you tell me where you found these? I removed all the ones I could find, and you could save me some tedious searching if you know where they are.

Sorry--sure.

1. util/glrad.c--strchr() (I was wrong about the function, too.) Probably the #ifdef BSD that covers it with index() could be dropped, too, since strchr() is part of C90.

2. hd/rhd_ogl.c--index(). Ironically, the declaration (in dev_section()) does not seem to actually be used, but still creates a compile-time error.

Anyone who doubts Greg's position on conditional compilation, take note.

2. The provided version of libtiff does not compile in that environment; the configure script fails. I suspect a conflict with the system's version of "bash," which may have a bug--it is "unstable," after all. The current version of libtiff compiles, but I did not test its functionality. Libtiff is actually available on that platform as the Debian package libtiffg3.

I don't know enough abot libtiff's build process to hack it. There are some problems on Solaris as well.

My compile-time problems were cleared by downloading the latest release (3.5.7) from Debian; I expect the version at www.libtiff.org is the the same. The only thing I had to do to get it to compile was to bring over the "configure.local" file from the old version. I do not, however, know that it will actually work, though I think it very likely. Note that LZW compression support is problematic, since that algorithm has been patented, though code is linked at libtiff.org.

3. That version of Linux supports OpenGL, but I had to hack makeall to get it built in.

You can add "ogl" to the SPECIAL= line of rmake -- you don't need to hack makeall, really.

Great, thanks!

Randolph

···

On Wednesday, May 14, 2003, at 09:45 PM, Greg Ward wrote:

I just checked in these changes -- sorry for the delay!

-Greg

···

From: Randolph Fritz <[email protected]>

1. util/glrad.c--strchr() (I was wrong about the function, too.) Probably the #ifdef BSD that covers it with index() could be dropped, too, since strchr() is part of C90.

2. hd/rhd_ogl.c--index(). Ironically, the declaration (in dev_section()) does not seem to actually be used, but still creates a compile-time error.