imfort under 64-bit
Philip Massey wrote on Feb 06, 2017
Hi, Mike et al.---
For several years my collaborator has been reducing our Magellan MagE data using Jack Baldwin's old "mtools" IRAF package which relies heavily on imfort. My collaborator has been running this on an ancient 32-bit laptop, and obviously this situation can't last forever. (There is a new Python pipeline out for MagE, but reports are that the IRAF reductions are higher S/N for a few poorly understood reasons.) Anyway, I would like to try to get this going on a modern machine; any suggestions? I've seen the 2006 post:
http://iraf.net/forum/viewtopic.php?showtopic=146144; I don't know if that's been tried.
Any suggestions for getting started would be helpful. Thanks!
cheers,
phil
Mike Fitzpatrick wrote on Feb 06, 2017
Hi Phil,
IMFORT was fully ported to 64-bit as part of the initial v2.15 release and so far as being able to run the example tasks indicates that it works, it works. Since imfort isn't heavily used much any more, and much of whether a specific task will work or not depends on whether *it* was ported to 64-bit, I didn't do extensive testing however. There may also be some slight differences depending on whether the C binding was used in a task.
There is more information about the 64-bit port at ftp://iraf.noao.edu/iraf/v216/PORT.GUIDE however this mostly applies to native SPP tasks. If you compile a task using the IRAF XC compiler (which layers on the IRAF F2C internally and which is normally called as the 'fc' command) then 'integer' datatypes declared in your code will automatically be promoted to 'long' to accommodate pointer values (e.g. the image pointer returned by imopen()), however if you compile yourself using e.g. G77 directly and simply link in the imfort libraries you may run into problems. The C-bindings were apparently NOT ported to 64-bit but that wouldn't be hard to do and from the look of the MTOOLS code doesn't look like it will affect you. Post back if you have any problems.
Cheers,
-Mike
Philip Massey wrote on Feb 06, 2017
Hi, Mike---
Thanks so much! I've downloaded the the Jack Baldwin "mtools" from
http://www.lco.cl/telescopes-information/magellan/instruments/mike/iraf-tools/iraf-mtools-package
There are two compile scripts that I've slightly modified; I'm using the Intel fortran compiler "ifort" in 64-bit mode.
ifort -o mikecrx mikecrx.f getimage.f putimage.f /iraf/iraf/bin.macintel/libimfort.a /iraf/iraf/bin.macintel/libsys.a /iraf/iraf/bin.macintel/libvops.a /iraf/iraf/unix/bin.macintel/libos.a -lm -L/usr/X11R6/lib -lX11
ifort -o mikesumx mikesumx.f getimage.f putec.f /iraf/iraf/bin.macintel/libimfort.a /iraf/iraf/bin.macintel/libsys.a /iraf/iraf/bin.macintel/libvops.a /iraf/iraf/unix/bin.macintel/libos.a -lm -L/usr/X11R6/lib -lX11
However, when I run these I get the following errors:
Undefined symbols for architecture x86_64:
"_i_len", referenced from:
_imemsg_ in libimfort.a(imemsg.o)
_f77pak_ in libvops.a(f77pak.o)
_f77upk_ in libvops.a(f77upk.o)
_imgdir_ in libimfort.a(imfdir.o)
"_pow_di", referenced from:
_dtcscl_ in libsys.a(dtcscl.o)
"_pow_ri", referenced from:
_dtoc_ in libsys.a(dtoc.o)
_dtoc3_ in libsys.a(dtoc3.o)
"_r_imag", referenced from:
_xtoc_ in libsys.a(xtoc.o)
"_s_copy", referenced from:
_imemsg_ in libimfort.a(imemsg.o)
_f77pak_ in libvops.a(f77pak.o)
Undefined symbols for architecture x86_64:
"_i_len", referenced from:
_imemsg_ in libimfort.a(imemsg.o)
_f77pak_ in libvops.a(f77pak.o)
_f77upk_ in libvops.a(f77upk.o)
_imgdir_ in libimfort.a(imfdir.o)
"_pow_di", referenced from:
_ctod_ in libsys.a(ctod.o)
_dtcscl_ in libsys.a(dtcscl.o)
"_pow_ri", referenced from:
_ctod_ in libsys.a(ctod.o)
_dtoc_ in libsys.a(dtoc.o)
_dtoc3_ in libsys.a(dtoc3.o)
"_r_imag", referenced from:
_xtoc_ in libsys.a(xtoc.o)
"_s_copy", referenced from:
_imemsg_ in libimfort.a(imemsg.o)
_f77pak_ in libvops.a(f77pak.o)
Naively I'm reading this as some of the imfort routines not being defined under 64-bits.
Thoughts? I'm running 2.16.1 on a Mac.
Thanks!
Mike Fitzpatrick wrote on Feb 06, 2017
I think the problem is actually a missing libf2c.a for some of the functions as well as a difference in naming scheme for the imfort tasks (i.e. a pre/postfixed underscore). In general something like the Intel fortran compiler isn't supported and in a worst case would require that the entire IRAF system be recompiled using it. You would be better off just using the native FC/XC compiler for this package (any loss of optimization by the intel compiler would still make it infinitely faster than a package that wouldn't compile at all).
Philip Massey wrote on Feb 06, 2017
Hi, Mike---
Okay, thanks! Progress is definitely being made, but I'm not there yet. Any further help would be greatly appreciated.
When I do a
xc -o mikecrx mikecrx.f getimage.f putimage.f /iraf/iraf/bin.macintel/libimfort.a /iraf/iraf/bin.macintel/libsys.a /iraf/iraf/bin.macintel/libvops.a /iraf/iraf/unix/bin.macintel/libos.a -lm -L/usr/X11R6/lib -lX11
I get the following:
mikecrx.c:152:1: warning: control reaches end of non-void function [-Wreturn-type]
} /* MAIN__ */
^
1 warning generated.
getimage.f:
getimage:
putimage.f:
putimage:
link:
Undefined symbols for architecture x86_64:
"_xargc", referenced from:
_getarg_ in libf2c.a(getarg_.o)
"_xargv", referenced from:
_getarg_ in libf2c.a(getarg_.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Similarly if I do a
xc -o mikesumx mikesumx.f getimage.f putec.f /iraf/iraf/bin.macintel/libimfort.a /iraf/iraf/bin.macintel/libsys.a /iraf/iraf/bin.macintel/libvops.a /iraf/iraf/unix/bin.macintel/libos.a -lm -L/usr/X11R6/lib -lX11
I get the same errors.
I get:
mikesumx.c:597:1: warning: control reaches end of non-void function [-Wreturn-type]
} /* MAIN__ */
^
1 warning generated.
getimage.f:
getimage:
putec.f:
putec:
link:
Undefined symbols for architecture x86_64:
"_xargc", referenced from:
_getarg_ in libf2c.a(getarg_.o)
"_xargv", referenced from:
_getarg_ in libf2c.a(getarg_.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I tried looking for the libf2c.a library you mentioned, but I don't see it under bin.macintel.
Thanks!
---phil
Mike Fitzpatrick wrote on Feb 06, 2017
For imfort programs you need to use "xc -h" to compile a "host" program. You'll also need to include $iraf/unix/bin.macintel/libf2c.a in the link line (note "$iraf/unix/bin.macintel", not "$iraf/bin.macintel"). All of this is done automatically with the 'fc' task alias and libf2c is normally included in the XC link command, but not having the '-h' may mean the main() isn't being linked in and hence the missing xargc/xargv.
Philip Massey wrote on Feb 06, 2017
Fantastic! Yes, including the -h flat meant that the xargc/xargv problem disappeared; as you suggested, I didn't have to explicitly include the iraf/unix/bin.macintel/libf2c.a
library. I am getting a somewhat mysterious warning message, but I do have an executable which I can test!
mikecrx.f:
MAIN:
mikecrx.c:152:1: warning: control reaches end of non-void function [-Wreturn-type]
} /* MAIN__ */
^
1 warning generated.
getimage.f:
getimage:
putimage.f:
putimage:
link:
I see a similar warning with the other one:
ikesumx.c:597:1: warning: control reaches end of non-void function [-Wreturn-type]
} /* MAIN__ */
^
1 warning generated.
getimage.f:
getimage:
putec.f:
putec:
link:
Actually I tried a "hello world" and I seem to get a similar warning no matter what program I compile:
MAIN:
test.c:31:1: warning: control reaches end of non-void function [-Wreturn-type]
} /* MAIN__ */
^
1 warning generated.
link:
[d106-41:iraf/mike_tools/iraf] massey%
So, I guess this is just not something to worry about.
Thanks for your help! We'll try using this tonight and seeing if it all works....
best regards,
phil
Mike Fitzpatrick wrote on Feb 06, 2017
It's just a warning saying that procedure doesn't explicitly return a value (which could be a bug so check it out anyway). To turn it off use
xc -h -/Wreturn-type .....Philip Massey wrote on Feb 07, 2017
We tried it out last night and successfully reduced some data, so all is good! Thanks again for your help!
If anyone is interested in knowing how to install Jack Baldwin's "mtools" (useful for reducing MIKE or MagE data), see http://www2.lowell.edu/users/massey/Macsoftware.html
Last post on Feb 07, 2017