Dear Group,
I am attempting to compile Radiance using Microsoft's Services for Unix (Interix 3.5). There are some problems that I am encountering. I have gotten some of Radiance's utilities to compile (about 50 total) but I have run into some issues in getting the core rendering programs (rpict and rtace) to compile. I am willing to forgo rview while using Interix and use this feature with Cygwin. Here are there error messages that I received while attempting to compile the core rendering utilities:
persist.c:37: error: conflicting types for `sighandler_t'
/usr/include/signal.h:40: error: previous declaration of `sighandler_t'
persist.c: In function `pfhold':
persist.c:129: warning: passing arg 1 of `mkfifo' makes pointer from integer wit
hout a cast
persist.c:131: warning: passing arg 1 of `mkfifo' makes pointer from integer wit
hout a cast
persist.c:134: warning: passing arg 1 of `mkfifo' makes pointer from integer wit
hout a cast
persist.c:152: error: cast specifies function type
ambient.c: In function `ambsync':
ambient.c:891: warning: assignment makes pointer from integer without a cast
I should note that I am using the latest CVS snapshop (I downloaded within the last 30 minutes). Can anyone help me?
Thanks
Marcus
Hi Marcus,
I came across this problem when compiling Radiance under Interix. I
resolved it by commenting out these three lines near the top of the file
persist.c:
typedef void (sighandler_t)(int);
static sighandler_t sig_io;
static sighandler_t sig_alrm;
I should warn you that I didn't look into the problem too deeply, so
that may or may not be the best solution!
There are a couple of other problems you might want to watch out for (I
ran into these when compiling an older version of Radiance so maybe
you'll be ok with the most recent version).
I had a problem compiling the tiff library (in ray/src/px/tiff). The
problem was caused by the config.guess file which didn't recognise
Interix. I found an updated version elsewhere which I can send to you
if you need it.
Finally, I found that I was getting some very strange results from rpict
(see
http://www.radiance-online.org/pipermail/radiance-dev/2003-November/0002
53.html). The problem seemed to be caused by Interix's implementation
of the frexp() function. At the time there was an alternative version
of that function with the Radiance source which fixed the problem. It
seems that the alternative was removed from the Radiance source at some
point since then, so that option is no longer available. You might have
a more recent version of Interix that does not require the fix (you will
know if you have the problem because all of the images produced by rpict
will be obviously wrong). Personally I switched to using Cygwin.
Best regards,
Andy Stone
Date: Fri, 10 Feb 2006 03:29:33 +0000
From: "Marcus Jacobs" <marcdevon@hotmail.com>
Subject: [Radiance-dev] Compile Problems with Interix
To: radiance-dev@radiance-online.org
Message-ID: <BAY102-F32B1FAA42E71AA4A5CC5B5A4020@phx.gbl>
Content-Type: text/plain; format=flowed
Dear Group,
I am attempting to compile Radiance using Microsoft's Services for
Unix
(Interix 3.5). There are some problems that I am encountering. I have
gotten
some of Radiance's utilities to compile (about 50 total) but I have
run
into
some issues in getting the core rendering programs (rpict and rtace)
to
compile. I am willing to forgo rview while using Interix and use this
feature with Cygwin. Here are there error messages that I received
while
attempting to compile the core rendering utilities:
persist.c:37: error: conflicting types for `sighandler_t'
/usr/include/signal.h:40: error: previous declaration of
`sighandler_t'
persist.c: In function `pfhold':
persist.c:129: warning: passing arg 1 of `mkfifo' makes pointer from
integer
wit
hout a cast
persist.c:131: warning: passing arg 1 of `mkfifo' makes pointer from
integer
wit
hout a cast
persist.c:134: warning: passing arg 1 of `mkfifo' makes pointer from
integer
wit
hout a cast
persist.c:152: error: cast specifies function type
ambient.c: In function `ambsync':
ambient.c:891: warning: assignment makes pointer from integer without
a
cast
I should note that I am using the latest CVS snapshop (I downloaded
within
···
the last 30 minutes). Can anyone help me?
Thanks
Marcus
Thanks for the info Andy. I did do a keyword search on ‘Interix’ and it seemed like Greg and yourself took your correspondence out of this forum so I am unsure of what became of this. Hey, at least you had some success in getting your code to compile. I am not even there yet.
I do not know if I want to start commenting out statements within the source code. This is like having a annoying rattling bolt in your car engine or suspension and just haphazardly removing it in order to alleviate the noise without knowing if you removed a critical part. I do want a stable, robust solution to this problem (if it exist at all). I asked a question some time ago about compiling programs on SFU on Interop System’s forum. One of the gurus there said “Read through the FAQ’s about porting stuff; what options to define (”-D") etc. It makes a big difference, particularly WRT to header files. Interix aims to be SUS compliant." The section in the FAQ that he was alluding to I believe is this:
Using GNU�s configureWhen using GNU’s configure script to configure a build environment for an application it is suggested that you set the following environment variables before running configure.****
** CFLAGS="-D_ALL_SOURCE -D_REENTRANT"
** CPPFLAGS="-D_ALL_SOURCE -D_REENTRANT -I/usr/local/include"**
** LDFLAGS="-L/usr/local/lib"**
If GNU’s configure complains that the type of system is not recognized then you need to update the file “config.guess.” Some applications have multiple copies of “config.guess” so be sure to find all of them. An updated “config.guess” can be downloaded from “ftp://ftp.interopsystems.com/pub/config.guess”. You may also need to update your LD_LIBRARY_FLAGS if you are using shared object libraries (DSOs), but this is likely already done for you if you have installed a /Tools packaged library.**
I don’t know if this will help but I guess its worth a shot.
I assume that you compiled Radiance using gcc. I am doing the same although I may try to port it to Windows using Microsoft C compiler later in the future (if it is at all possible). There is also a beta version of gcc 4.0 available for Interix on Interop System’s FTP site. This is something worth looking in to but I do not believe that this will help my situation. I think the problems that I am having are related SFU’s standard libraries.
Before giving up on this all together, I really would like to evaluate Interix as a Windows solution for Radiance. Since it does support a NFS, I may be able to finally utilize multiple processors via rpiece.
Thanks for your suggestions.
Marcus
···
Andy Stone wrote:
Hi Marcus,
I came across this problem when compiling Radiance under Interix. I
resolved it by commenting out these three lines near the top of the file
persist.c:
typedef void (sighandler_t)(int);
static sighandler_t sig_io;
static sighandler_t sig_alrm;
I should warn you that I didn’t look into the problem too deeply, so
that may or may not be the best solution!
There are a couple of other problems you might want to watch out for (I
ran into these when compiling an older version of Radiance so maybe
*you’ll be ok with the most recent version). *
I had a problem compiling the tiff library (in ray/src/px/tiff). The
problem was caused by the config.guess file which didn’t recognise
Interix. I found an updated version elsewhere which I can send to you
*if you need it. *
Finally, I found that I was getting some very strange results from rpict
(see
http://www.radiance-online.org/pipermail/radiance-dev/2003-November/0002
53.html). The problem seemed to be caused by Interix’s implementation
of the frexp() function. At the time there was an alternative version
of that function with the Radiance source which fixed the problem. It
seems that the alternative was removed from the Radiance source at some
point since then, so that option is no longer available. You might have
a more recent version of Interix that does not require the fix (you will
know if you have the problem because all of the images produced by rpict
will be obviously wrong). Personally I switched to using Cygwin.
Best regards,
Andy Stone
Thanks for the info Andy. I did do a keyword search on 'Interix' and it seemed like Greg and yourself took your correspondence out of this forum so I am unsure of what became of this. Hey, at least you had some success in getting your code to compile. I am not even there yet.
I do not know if I want to start commenting out statements within the source code. This is like having a rattling bolt in your car engine or suspension and just haphazardly removing it in order to alleviate the situation without knowing if you removed a critical part. I do want a stable, robust solution to this problem (if it exists at all). I asked a question some time ago about compiling programs on SFU on Interop System's forum. One of the gurus there said "Read through the FAQ's about porting stuff; what options to define ("-D") etc. It makes a big difference, particularly WRT to header files. Interix aims to be SUS compliant." The section in the FAQ that he was alluding to I believe is this:
Using GNU�s configure
When using GNU's configure script to configure a build environment for an application it is suggested that you set the following environment variables before running configure.
CFLAGS="-D_ALL_SOURCE -D_REENTRANT"
CPPFLAGS="-D_ALL_SOURCE -D_REENTRANT -I/usr/local/include"
LDFLAGS="-L/usr/local/lib"
If GNU's configure complains that the type of system is not recognized then you need to update the file "config.guess." Some applications have multiple copies of "config.guess" so be sure to find all of them. An updated "config.guess" can be downloaded from "ftp://ftp.interopsystems.com/pub/config.guess". You may also need to update your LD_LIBRARY_FLAGS if you are using shared object libraries (DSOs), but this is likely already done for you if you have installed a /Tools packaged library.
I don't know if this will help but I guess it�s worth a shot. Can anyone provide some insight as to what all of this means?
I assume that you compiled Radiance using gcc. I am doing the same although I may try to port it to Windows using Microsoft�s C compiler later in the future (if it is at all possible). There is also a beta version of gcc 4.0 available for Interix on Interop System's FTP site. This is something worth looking in to but I do not believe that this will help my situation. I think the problems that I am having are related SFU's standard libraries.
Before giving up on this all together, I really would like to evaluate Interix as a Windows solution for Radiance. Since it does support a NFS, I may be able to finally utilize multiple processors via rpiece. Thanks for your suggestions.
Marcus