iraf.net

I'm trying to compile IRAF 2.15.1a from source, but running into problems making 64 bit executables.In file included from setbuf.c:10:
libc_proto.h:20: error: conflicting types for `c_close'
/arzach/data1/sienkiew/iraf/unix/hlib/libc/libc.h:157: error: previous declaration of `c_close' was here
... repeat for c_close, c_envlist, c_envmark, c_flush, c_fredir, ...The pattern seems to be that anything in libc.h that has a parameter type of XINT is in conflict with the same parameter as defined in sys/libc/libc_proto.hLine 15 of libc.h defines XINT to be "long" not "int". libc.h uses XINT, but libc_proto.h uses int. The actual function definitions often use XINT.( It works ok to make 32 bit executables because in that case XINT is int, which matches libc_proto.h. )So, how does it work to compile 64 bit binaries?

For 64-bit you need to be sure your IRAFARCH variable is set to either 'linux64' or 'macintel' depending on your platform. You'll also need to be sure the install script was run so there is a valid /usr/include/iraf.h link, and that the system was configured for the proper architecture. All you should need to do is something like:[code:1:a67f079fd9]
% cd /iraf/iraf
% make linux64
% make sysgen
[/code:1:a67f079fd9]It sounds like the iraf.h file for your system is still the 32-bit version and that the system isn't configured for the proper architecture (i.e. is the 'bin' link pointing to bin.generci?).

IRAFARCH=macintel and bin is a symlink to bin.macintel (that "make $IRAFARCH" created)I do not have /usr/include/iraf.h at all. I don't have root so I am using $HOME/.iraf as provided for by irafuser.csh. It requires a few tweaks to the install script, but nothing that I would expect to affect the content of the include file. e.g. copy iraf.h to $HOME/.iraf instead of /usr/include, that kind of thing.The files needed in $HOME/.iraf are iraf.h, f2c.h, vosproto.h, and yaccpar.x; I also had to explicitly compile f2c and libf2c.a. Other than minor stuff like that, everything goes pretty smoothly on a 32 bit linux machine.On the 64 bit mac, the problem appears to be an inconsistency between libc_proto.h and libc.h. Is there a different libc_proto.h for 32 and 64 bit machine? If not, which is the correct type for the integer parameters - int or XINT ?

[quote:9f7b666528]On the 64 bit mac, the problem appears to be an inconsistency between libc_proto.h and libc.h. Is there a different libc_proto.h for 32 and 64 bit machine? If not, which is the correct type for the integer parameters - int or XINT ?[/quote:9f7b666528]The libc_proto.h file isn't actually used anywhere in the code so I'm not sure why you're getting any sort of complaint about it. Did you modify something locally? If so, what and how?The definition of XINT depends on 'MACH64' being defined during compilation, specifically when including the hlib$libc/libc.h file as when compiling the LIBC interface for the HSI. Does "xc -c -dv setbuf.c" show the following:[code:1:9f7b666528]munch> xc -c -dv setbuf.c
cc -c -DMACH64 -DMACOSX -arch x86_64 -m64 -v -I/iraf/iraf/unix/hlib/libc setbuf.c
.....
[/code:1:9f7b666528]If not your environment might not be defined correctly. Lastly, if you modified the install script did you make sure that the hlib$libc/iraf.h file was also modified with the path to your iraf installation?Is there some particular reason other than curiosity you're trying to compile from sources? Also, are you actually on a 64-bit system (i.e. does "uname -a" show the arch as "x86_64"?) or are you trying to cross-compile on a 'macosx' native irafarch (which won't work, BTW).

[quote:5767454502="fitz"]
The libc_proto.h file isn't actually used anywhere in the code so I'm not sure why you're getting any sort of complaint about it. Did you modify something locally? If so, what and how?
[/quote:5767454502]That's the clue I needed. I found one of my 2.14 patches in my 2.15 patch collection. It must have been copied by mistake; eliminating it fixes the problem. Sorry for the false alarm.[quote:5767454502]
Is there some particular reason other than curiosity you're trying to compile from sources?
[/quote:5767454502]There are a few. Most notable is that I am tasked with making a distribution of astronomy software that includes Python and IRAF. One of the requirements is that it should not require superuser privileges to install. Another is that a single user may have multiple versions of the distribution installed at the same time. Python meets those requirements as-is. IRAF is really close but /iraf, /usr/include/iraf.h, and /usr/local/lib/imtoolrc are a problem. Other than those few files, IRAF doesn't actually do anything that should require root privs[1], so it should be relatively easy to make a patch to make it all work off $iraf instead of fixed path names. Of course, before I can apply a patch, I need to be able to compile the software.Once I have that motivation, I get a bonus for free: The tasks we use come from many different origins, and some have such poor error checking that a common response to bad input is just to seg fault. A crash deep inside VOS is rarely the fault of VOS -- it is the application program that tried to do IO to a file even though the open failed or some such. If I can compile IRAF, I can more easily insert diagnostics at various points to help debug the problem.[quote:5767454502]
Also, are you actually on a 64-bit system (i.e. does "uname -a" show the arch as "x86_64"?) or are you trying to cross-compile on a 'macosx' native irafarch (which won't work, BTW).[/quote:5767454502]
The 64 bit linux machines self-identify as x86_64. The Macs that are 64-bit capable self-identify as "i386" on both Leopard and Snow Leopard. IMHO, that is just wrong, but Apple does stuff like that.I'll be happy to send you my patch when I get it working, but it may be a while because there is another higher priority project that is demanding a lot of my time. I don't expect the patch to be very extensive, though.Mark S.[1] Of course, I'm ignoring the program that grants access to tape drives. I know we have some tape drives at the institute somewhere, but people don't have them on their workstations.