Welcome to iraf.net Tuesday, July 25 2017 @ 08:45 AM GMT


 Forum Index > Help Desk > Applications New Topic Post Reply
 imfort under 64-bit
   
massey
 02/06/2017 01:13PM (Read 608 times)  
+++++
Active Member

Status: offline


Registered: 02/10/2006
Posts: 158
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

 
Profile Email Website
 Quote
fitz
 02/06/2017 04:35PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3965
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


 
Profile Email
 Quote
massey
 02/06/2017 05:39PM  
+++++
Active Member

Status: offline


Registered: 02/10/2006
Posts: 158
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!


 
Profile Email Website
 Quote
fitz
 02/06/2017 05:48PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3965

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).

 
Profile Email
 Quote
massey
 02/06/2017 06:22PM  
+++++
Active Member

Status: offline


Registered: 02/10/2006
Posts: 158
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



 
Profile Email Website
 Quote
fitz
 02/06/2017 06:31PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3965
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.

 
Profile Email
 Quote
massey
 02/06/2017 06:43PM  
+++++
Active Member

Status: offline


Registered: 02/10/2006
Posts: 158
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

 
Profile Email Website
 Quote
fitz
 02/06/2017 06:46PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 3965
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

PHP Formatted Code
xc -h -/Wreturn-type .....

 
Profile Email
 Quote
massey
 02/07/2017 02:49PM  
+++++
Active Member

Status: offline


Registered: 02/10/2006
Posts: 158
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

 
Profile Email Website
 Quote
   
Content generated in: 0.97 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login