iraf.net

We have a package that I'm trying to compile for iraf 2.16-linux-64 bit. In several places I get a string of errors like this:In file included from /iraf/iraf/unix/hlib/libc/stdio.h:9,
from map.c:12:
/iraf/iraf/unix/hlib/libc/libc.h:323:17: error: f2c.h: No such file or directory
In file included from /iraf/iraf/unix/hlib/libc/libc.h:324,
from /iraf/iraf/unix/hlib/libc/stdio.h:9,
from map.c:12:
/iraf/iraf/unix/hlib/libc/vosproto.h:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ahivx_’
/iraf/iraf/unix/hlib/libc/vosproto.h:2: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘alovx_’
/iraf/iraf/unix/hlib/libc/vosproto.h:3: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘amedx_’This keeps going with hundreds of errors from vosproto.h.It looks like the problem is from f2c.h not being found. Presumable it should be using the copy in /iraf/iraf/unix/bin.linux64.
I've verified the usual suspects and they seem ok.
%>echo $IRAFARCH
linux64
%>echo $iraf
/iraf/iraf/I've tracked down map.c and a couple of other culprits and verified that they have compiled under earlier versions of iraf (2.13)Any ideas about fixing this?Richard Clark

The problem is that the 'f2c.h' file cannot be found and so the 'C_f' type definition in vosproto.h isn't valid. Check that $iraf/unix/bin.linux64 contains an f2c.h, and/or that you are compiling the source with a "-I/iraf/iraf/unix/bin.linux64" flag.Are you using XC to compile map.c or calling 'cc' directly?

[quote:8a6da250be="fitz"]The problem is that the 'f2c.h' file cannot be found and so the 'C_f' type definition in vosproto.h isn't valid. Check that $iraf/unix/bin.linux64 contains an f2c.h, and/or that you are compiling the source with a "-I/iraf/iraf/unix/bin.linux64" flag.Are you using XC to compile map.c or calling 'cc' directly?[/quote:8a6da250be]Hi Mike,The f2c.h file is present in /iraf/iraf/unix/bin.linux64 and has an #include for the vosproto.h file.It looks like xc is being used. There is an explicit xc call but it is for linking several .o and lib files to make the executable. The map.c and map3.c files that cause the problems are compiled as part of an 'update libpkg' in the mkpkg file.The mkpkg files are being called from a shell command, not from within the cl.
The mkpkg files are being called from within Makefile wrappers through the several subpackages that I'm not the author of. So there could be some interactions there that I'm not aware of.Richard

My guess then is that you need to compile this file (and those like it) using the '-Inolibc' flag. If the source includes things like <stdio.h> then without that flag you're getting the stdio.h from hlib$libc and not the host /usr/include that it usually refers to. You can add a line such as[code:1:837bffe31d]$set XFLAGS = "$(XFLAGS) -Inolibc"[/code:1:837bffe31d]to the mkpkg file to set this flag.

I'm mot quite sure where to put the -I/iraf/iraf/unix/bin.linux64 (or
-Inolibc). The only explicit xc statements in the mkpkg are to link the .o
and .a files to produce the executable, and to compile a (non troublesom)
c program. The bulk of the compiling is implied by the 'omake' and 'update
libpkg.a' statements.I have tried listing f2c.h on the entry for map.c in the update libpkg
block. map.c "/iraf/iraf/unix/bin.linux64/f2c.h"
map3.c "$(iraf)unix/bin.$(IRAFARCH)/f2c.h"(see the originals below). Both of these seem to be syntacticly
correct but do not eliminate the cascade of errors.Is there any way, or need, to distinguish between the search paths for spp
and c header files?Richard
---------------------------
mkpkg is called in a Makefile which looks like
# Makefile for grasp/pkg/pipeline/dnspipe2
#
# Targets here are:
# clean
# all
#SHELL=/bin/shall:
mkpkg -p grasp -p tables allclean:
mkpkg -p grasp clean---------------------------
The mkpkg looks like
# This is the mkpkg file for grasp/pkg/pipeline/dnspipe2
# all:
$call x_dnspipe.e
;x_dnspipe.e:
$set LIBS1 = "-liminterp ../../../obj/libgrutil.a -lm"
$set LIBS2 = "../../../obj/libmagmerge.a -lm"
$call version.o
$update libpkg.a
$omake x_dnspipe.x
$set OBJECT = "x_dnspipe2.e"
$xc x_dnspipe.o version.o libpkg.a $(LIBS1) $(LIBS2) -o $(OBJECT)
$move $(OBJECT) ../../../obj/$(OBJECT)
;version.o:
$xc -c version.c
;libpkg.a:
t_dnspipe.x <imhdr.h> <imset.h> <math.h> <math/iminterp.h> \
<grutil.h> "dnspipe.h"
t_hgremap.x <imhdr.h> <imset.h> <math.h> <math/iminterp.h> \
<grutil.h> "dnspipe.h"
t_hgremap3.x <imhdr.h> <imset.h> <math.h> <math/iminterp.h> \
<grutil.h> "dnspipe.h"
dns_apodize.x <math.h> <mach.h> "dnspipe.h"
dns_filter.x "dnspipe.h"
dns_fluxcon.x <math.h> <math/iminterp.h> "dnspipe.h"
...
dns_turret.x <imhdr.h> <math.h>
Bessel_i0.x
Dolph_Cheby.x <math.h>
fftrc.f
fourt.f
map.c
map3.c
;clean:
!/bin/rm -rf *.o *.a *.e *~; echo > /dev/null
;

Try putting the "$set XFLAGS = ....." line right after your '$set LIBS2 = ...." line so it will apply to all files compiled for the binary. I assume all your C sources are "plain C" code and not meant to build on the IRAF libc interface?

Thamks Mike,Adding an XFLAGS line fixed it up.Richard