fc command gives unusual output, segmentation fault
mdykhuis wrote on Jul 13, 2011
Hi,
I'm trying to compile and run fortran programs using IRAF (version 2.15.1a) using the 'fc' command. On my linux computer, the output of the 'fc' command 'fc hello.f' is sweet and simple:
and produces the .o and .e files as expected.
On my Mac (10.6.8 Snow Leopard, Intel Core Duo 32-bit, uname -m = i386), the same command gives 86 lines of output (see below). The .o and .e files are created, and the .e runs, unless the fortran code has a call to read the arguments (e.g. "call clnarg(nargs)"), in which case it gives a segmentation fault.
The obvious workaround is to omit any attempts to read arguments, but this is not satisfactory in the long term. I'm new to this, and not familiar with the output given below. Can anyone take a more experienced look at the output and help me out? Thanks in advance.
-MD
My program:
The output:
I'm trying to compile and run fortran programs using IRAF (version 2.15.1a) using the 'fc' command. On my linux computer, the output of the 'fc' command 'fc hello.f' is sweet and simple:
hello.f:
MAIN hello:
link:and produces the .o and .e files as expected.
On my Mac (10.6.8 Snow Leopard, Intel Core Duo 32-bit, uname -m = i386), the same command gives 86 lines of output (see below). The .o and .e files are created, and the .e runs, unless the fortran code has a call to read the arguments (e.g. "call clnarg(nargs)"), in which case it gives a segmentation fault.
The obvious workaround is to omit any attempts to read arguments, but this is not satisfactory in the long term. I'm new to this, and not familiar with the output given below. Can anyone take a more experienced look at the output and help me out? Thanks in advance.
-MD
My program:
program hello
call clnarg(nargs)
if(nargs.gt.0) then
print *,"I read the argument."
else
print *,"No argument."
endif
print *,"Hello."
stop
end
The output:
ecl> fc hello.f
+ PATH=/v/bin:/bin:/usr/bin:/usr/local/bin
+ s=/tmp/stderr_11125
+ t=/tmp/f77_11125
+ CC=gcc
+ CFLAGS=-I/iraf/iraf/unix/bin.macosx
+ EFL=/v/bin/efl
+ EFLFLAGS='system=portable deltastno=10'
+ F2C=/usr/bin/f2c
+ F2CFLAGS='-KRw8 -Nn802'
+ keepc=0
+ warn=1
+ xsrc=0
+ rc=0
+ lib=/lib/num/lib.lo
+ trap 'rm -f /tmp/stderr_11125 ; exit $rc' 0
+ OUTF=a.out
+ cOPT=1
+ G=
+ CPP=/bin/cat
+ CPPFLAGS=
+ case $? in
+ test X-c '!=' X--
+ case "$1" in
+ cOPT=0
+ shift
+ test X-f2c '!=' X--
+ case "$1" in
+ F2C=/iraf/iraf/unix/bin.macosx/f2c.e
+ shift 2
+ test X-arch '!=' X--
+ case "$1" in
+ CFLAGS='-I/iraf/iraf/unix/bin.macosx -arch ppc'
+ shift 2
+ test X-arch '!=' X--
+ case "$1" in
+ CFLAGS='-I/iraf/iraf/unix/bin.macosx -arch ppc -arch i386'
+ shift 2
+ test X-m32 '!=' X--
+ case "$1" in
+ CFLAGS='-I/iraf/iraf/unix/bin.macosx -arch ppc -arch i386 -m32'
+ shift 1
+ test X-mmacosx-version-min=10.4 '!=' X--
+ case "$1" in
+ CFLAGS='-I/iraf/iraf/unix/bin.macosx -arch ppc -arch i386 -m32 -mmacosx-version-min=10.4'
+ shift 1
+ test X-arch '!=' X--
+ case "$1" in
+ CFLAGS='-I/iraf/iraf/unix/bin.macosx -arch ppc -arch i386 -m32 -mmacosx-version-min=10.4 -arch ppc'
+ shift 2
+ test X-arch '!=' X--
+ case "$1" in
+ CFLAGS='-I/iraf/iraf/unix/bin.macosx -arch ppc -arch i386 -m32 -mmacosx-version-min=10.4 -arch ppc -arch i386'
+ shift 2
+ test Xhello.f '!=' X--
+ case "$1" in
+ set -- -- hello.f
+ test X-- '!=' X--
+ shift
+ test -n hello.f
+ case "$1" in
+ case "$1" in
+ f=.f
++ basename hello.f .f
+ b=hello
+ '[' 1 = 0 ']'
+ /iraf/iraf/unix/bin.macosx/f2c.e -KRw8 -Nn802 hello.f
hello.f:
MAIN hello:
+ '[' 0 = 1 ']'
+ gcc -c -I/iraf/iraf/unix/bin.macosx -arch ppc -arch i386 -m32 -mmacosx-version-min=10.4 -arch ppc -arch i386 hello.c
+ rc=0
+ sed '/parameter .* is not referenced/d;/warning: too many parameters/d' /tmp/stderr_11125
+ case $rc in
+ '[' 0 = 0 ']'
+ rm -f hello.c
+ OFILES=' hello.o'
+ case $cOPT in
+ shift
+ test -n ''
+ case $cOPT in
+ rc=0
+ exit 0
+ rm -f /tmp/stderr_11125
+ exit 0
link:
Mike Fitzpatrick wrote on Jul 13, 2011
The additional output from the 'fc' command looks like the hlib$f77.sh script has the '-x' trace flag enabled but I don't see where that was done in any of the distributed files, did you change this locally? Is this a scisoft package?
Otherwise, there does appear to be a problem with reading command-line arguments from IMFORT on 64-bit systems. Since this is done by probing the environment stack it's likely related to the 64-bit port, however I remember fixing something similar to this when the port was originally done. I will investigate further when I return from travel next week and let you know what I find, for the moment I'm afraid there is no workaround other than to use a 32-bit system.
Otherwise, there does appear to be a problem with reading command-line arguments from IMFORT on 64-bit systems. Since this is done by probing the environment stack it's likely related to the 64-bit port, however I remember fixing something similar to this when the port was originally done. I will investigate further when I return from travel next week and let you know what I find, for the moment I'm afraid there is no workaround other than to use a 32-bit system.
mdykhuis wrote on Jul 13, 2011
Hi Mike,
Thanks again for the quick reply. I found the -x flag and disabled it, and the verbose output is gone. I didn't change this locally, it came with my scisoft package, from http://www.stsci.edu/~npirzkal/Scisoft/downloads/Intel/10.6.x/2011.4.1/
This is the April release for Mac OS X.
I am running a 32-bit system, and I still get a seg fault when I try to read command-line arguments, but I'm fine with my workaround for now (omitting the offending code sections). Enjoy your traveling.
-MD
Thanks again for the quick reply. I found the -x flag and disabled it, and the verbose output is gone. I didn't change this locally, it came with my scisoft package, from http://www.stsci.edu/~npirzkal/Scisoft/downloads/Intel/10.6.x/2011.4.1/
This is the April release for Mac OS X.
I am running a 32-bit system, and I still get a seg fault when I try to read command-line arguments, but I'm fine with my workaround for now (omitting the offending code sections). Enjoy your traveling.
-MD
Mike Fitzpatrick wrote on Jul 13, 2011
I've fixed the problem, recent versions of OSX no longer allow you direct access to the environment pointer when using dynamic libs (and all OSX binaries use the dynamic libSystem), however there is an obscure routine that does the job.
I've put patched versions of libos.a in the ftp://iraf.noao.edu/iraf/v215/support/<arch>; directory (where <arch> is either 'macosx' for 32-bit ppc/intel or 'macintel' for 64-bit intel). Replace the file in your $iraf/unix/bin.<arch> and relink your programs and you should be able to use the cmdline args again.
I've put patched versions of libos.a in the ftp://iraf.noao.edu/iraf/v215/support/<arch>; directory (where <arch> is either 'macosx' for 32-bit ppc/intel or 'macintel' for 64-bit intel). Replace the file in your $iraf/unix/bin.<arch> and relink your programs and you should be able to use the cmdline args again.
mdykhuis wrote on Jul 13, 2011
The patch fixes the problem. Thanks!
- MD
- MD
Last post on Jul 13, 2011