cl does not run
donzelli wrote on Oct 10, 2011
Hi,
I've downloaded the iraf-macosx.tar.gz file. After gunzip and tar -xvf I tried the cl command and I get the following message:
dyld: Symbol not found: ___stack_chk_guard
Referenced from: /iraf/iraf/bin.macosx/ecl.e
Expected in: /usr/lib/libSystem.B.dylib
Trace/BPT trap
This is a Power PC G4 with the Mac OS X 10.4.11.
Any help would be greatly appreciated.
Regards.
I've downloaded the iraf-macosx.tar.gz file. After gunzip and tar -xvf I tried the cl command and I get the following message:
dyld: Symbol not found: ___stack_chk_guard
Referenced from: /iraf/iraf/bin.macosx/ecl.e
Expected in: /usr/lib/libSystem.B.dylib
Trace/BPT trap
This is a Power PC G4 with the Mac OS X 10.4.11.
Any help would be greatly appreciated.
Regards.
Mike Fitzpatrick wrote on Oct 10, 2011
donzelli wrote on Oct 10, 2011
Thanks Fitz,
now cl runs properly.
However, I have now the following problem.
When I run gsextract (inside gemini, gmos packages) I get:
GSEXTRACT -- Tue Oct 11 08:57:48 BRST 2011
inimages = stgsS0116.fits
outimages =
outprefix = e
refimages =
apwidth = 1.
fl_inter = no
find = yes
recenter = yes
trace = no
tfunction = chebyshev
torder = 5
tnsum = 20
tstep = 50
weights = none
clean = no
background = none
fl_vardq = no
sci_ext = SCI
key_ron = RDNOISE
key_gain = GAIN
ron = 3.5
gain = 2.2
dyld: Symbol not found: ___stack_chk_guard
Referenced from: /iraf/iraf/bin.macosx/x_images.e
Expected in: /usr/lib/libSystem.B.dylib
ERROR: Abnormal termination of child process '??'
"imgets(l_image//"[0]","EXTEND", >& "dev$null")"
line 49: gemtools$gimverify.cl (hidden task)
called as: `gimverify (image=stgsS0116.fits)'
dyld: Symbol not found: ___stack_chk_guard
Referenced from: /iraf/iraf/bin.macosx/x_images.e
Expected in: /usr/lib/libSystem.B.dylib
ERROR: Abnormal termination of child process '??'
"sections (l_outprefix//"@"//tmpin, > tmpout)"
line 370: gmos$gsextract.cl
called as: `gsextract (mode=h)'
gmos>
I've checked the files and the files are there.
What have I missed?
regards
now cl runs properly.
However, I have now the following problem.
When I run gsextract (inside gemini, gmos packages) I get:
GSEXTRACT -- Tue Oct 11 08:57:48 BRST 2011
inimages = stgsS0116.fits
outimages =
outprefix = e
refimages =
apwidth = 1.
fl_inter = no
find = yes
recenter = yes
trace = no
tfunction = chebyshev
torder = 5
tnsum = 20
tstep = 50
weights = none
clean = no
background = none
fl_vardq = no
sci_ext = SCI
key_ron = RDNOISE
key_gain = GAIN
ron = 3.5
gain = 2.2
dyld: Symbol not found: ___stack_chk_guard
Referenced from: /iraf/iraf/bin.macosx/x_images.e
Expected in: /usr/lib/libSystem.B.dylib
ERROR: Abnormal termination of child process '??'
"imgets(l_image//"[0]","EXTEND", >& "dev$null")"
line 49: gemtools$gimverify.cl (hidden task)
called as: `gimverify (image=stgsS0116.fits)'
dyld: Symbol not found: ___stack_chk_guard
Referenced from: /iraf/iraf/bin.macosx/x_images.e
Expected in: /usr/lib/libSystem.B.dylib
ERROR: Abnormal termination of child process '??'
"sections (l_outprefix//"@"//tmpin, > tmpout)"
line 370: gmos$gsextract.cl
called as: `gsextract (mode=h)'
gmos>
I've checked the files and the files are there.
What have I missed?
regards
Mike Fitzpatrick wrote on Oct 10, 2011
The problem is the same in that the v2.15 binaries are not compatible with a 10.4 PPC system, I'd need to build a new set. However, the GEMINI package is still not able to use v2.15 so you'll need to install v2.14 anyway. See
ftp://iraf.noao.edu/iraf/v214/PCIX/
for the distribution files. Also, v2.14 external packages can be found in
ftp://iraf.noao.edu/iraf/extern-v214
Note this directory may not contain a full set of binaries for 'macosx'.
ftp://iraf.noao.edu/iraf/v214/PCIX/
for the distribution files. Also, v2.14 external packages can be found in
ftp://iraf.noao.edu/iraf/extern-v214
Note this directory may not contain a full set of binaries for 'macosx'.
donzelli wrote on Oct 10, 2011
Fitz,
thanks again, I'll install IRAF v2.14.
The Gemini version I have is 1.10 that was tested on IRAF v2.14, so I do not expect to have problems.
Should I expect to have problems with other extern pacakges such as fitsutil, misc, nmisc (needed for gemini)?
regards.
thanks again, I'll install IRAF v2.14.
The Gemini version I have is 1.10 that was tested on IRAF v2.14, so I do not expect to have problems.
Should I expect to have problems with other extern pacakges such as fitsutil, misc, nmisc (needed for gemini)?
regards.
donzelli wrote on Oct 10, 2011
Hi again,
well, not so sure about what I've said.
After installing IRAF v2.14 I ran the routine gsextract (gemini, gmos). While the routine was processing the data cl died, and I did not receive any error message, just the prompt in my home directory.
Any suggestions?
cheers
well, not so sure about what I've said.
After installing IRAF v2.14 I ran the routine gsextract (gemini, gmos). While the routine was processing the data cl died, and I did not receive any error message, just the prompt in my home directory.
Any suggestions?
cheers
Mike Fitzpatrick wrote on Oct 10, 2011
It's hard to tell exactly what failed: Are you using the ECL binary from earlier in the thread or the one that comes with the v2.14 distribution? What was the task doing at the time it exited, i.e. do you know if it was a GEMINI task, a core IRAF task, or some other external package task?
To track it down you could type "d_trace" before starting the task to trace the script execution an narrow things down. You might also try to attach a GDB debugger to the CL binary itself to trap an error in there. e.g. in another window
% ps -efw | grep ecl.e # get the process id
% gdb /iraf/iraf/bin.macosx/ecl.e <process_id>
... type 'c' to continue execution, GDB should break at an error
To track it down you could type "d_trace" before starting the task to trace the script execution an narrow things down. You might also try to attach a GDB debugger to the CL binary itself to trap an error in there. e.g. in another window
% ps -efw | grep ecl.e # get the process id
% gdb /iraf/iraf/bin.macosx/ecl.e <process_id>
... type 'c' to continue execution, GDB should break at an error
donzelli wrote on Oct 10, 2011
Hi Fitz,
thanks for your answer.
about your first question, I'm using ecl that comes with the v2.14 distribution.
about the second question, I just do not know. gsextract works for some seconds and I have no idea what is the routine in use when cl dies.
I've tried with d_trace and get what,
gsextract finished the process without errors!
In fact, I'm now watching the processed spectra!
On the other hand, if I do not type d_trace before running the routine, cl dies.
I'd keep it that way, but it's somewhat boring and slow to see the infinite list of processes on the screen each time you run a task.
regards
thanks for your answer.
about your first question, I'm using ecl that comes with the v2.14 distribution.
about the second question, I just do not know. gsextract works for some seconds and I have no idea what is the routine in use when cl dies.
I've tried with d_trace and get what,
gsextract finished the process without errors!
In fact, I'm now watching the processed spectra!
On the other hand, if I do not type d_trace before running the routine, cl dies.
I'd keep it that way, but it's somewhat boring and slow to see the infinite list of processes on the screen each time you run a task.
regards
Last post on Oct 10, 2011