mkpkg woes
Philip Massey wrote on Oct 15, 2007
I'm trying to install the external package rvsao on my Intel mac.
However, when I go to do the mkpkg there is a program
"writetemp.f" that won't compile:
In subroutine `tmpwrf':
writetemp.f:139:
if (.not.(debug .eq. .true.)) goto 130
1 2 3
Use .EQV./.NEQV. instead of .EQ./.NE. at (2) for LOGICAL operands at (1) and (3)
writetemp.f:153:
if (.not.(debug .eq. .true.)) goto 140
1 2 3
Use .EQV./.NEQV. instead of .EQ./.NE. at (2) for LOGICAL operands at (1) and (3)
Now, the thing driving me crazy is I can't even FIND writetemp.f.
I mean, it looks like a fortran program based on the extension, but
it is not in the rvsao tree.
Any suggestions would be appreciated...
thanks,
phil
However, when I go to do the mkpkg there is a program
"writetemp.f" that won't compile:
In subroutine `tmpwrf':
writetemp.f:139:
if (.not.(debug .eq. .true.)) goto 130
1 2 3
Use .EQV./.NEQV. instead of .EQ./.NE. at (2) for LOGICAL operands at (1) and (3)
writetemp.f:153:
if (.not.(debug .eq. .true.)) goto 140
1 2 3
Use .EQV./.NEQV. instead of .EQ./.NE. at (2) for LOGICAL operands at (1) and (3)
Now, the thing driving me crazy is I can't even FIND writetemp.f.
I mean, it looks like a fortran program based on the extension, but
it is not in the rvsao tree.
Any suggestions would be appreciated...
thanks,
phil
Mike Fitzpatrick wrote on Oct 15, 2007
Hi Phil,
The writetmp.f file is actually the result of compiling the SPP file rvsao$Makespec/writetmp.x. The errors are in the tmp_write_iraf() procedure on two lines that read:
Just change these to "if (debug) {" and all should be right with the world. You'll have to contact SAO to request they make a more permanent fix in future versions,
Cheers,
-Mike
The writetmp.f file is actually the result of compiling the SPP file rvsao$Makespec/writetmp.x. The errors are in the tmp_write_iraf() procedure on two lines that read:
if (debug == TRUE) {Just change these to "if (debug) {" and all should be right with the world. You'll have to contact SAO to request they make a more permanent fix in future versions,
Cheers,
-Mike
sirmarcos wrote on Oct 15, 2007
That's odd. I had compiled rvsao 2.5.0 on my intel mac some time ago without any problems and I just compiled 2.5.9 without incident as well. I could put the binaries up somewhere easily enough if you like.
Have you done the usual things, check that irafarch is properly defined, and that you did the mkpkg macintel command before mkpkg update?
hmmm, and what version of gcc/xcode are you using? (gcc_select without any arguments should tell you, I was using 4.0.1.)
I'm going to update my .pkg installer here in a bit, since I know have the newer binaries compiled.
Have you done the usual things, check that irafarch is properly defined, and that you did the mkpkg macintel command before mkpkg update?
hmmm, and what version of gcc/xcode are you using? (gcc_select without any arguments should tell you, I was using 4.0.1.)
I'm going to update my .pkg installer here in a bit, since I know have the newer binaries compiled.
Philip Massey wrote on Oct 15, 2007
Mike---
Thanks. There's an analogus problem in another routine:
if (tschop == FALSE && czr > 4.0) {
What should this be?
thanks,
phil </div> --- **Mike Fitzpatrick** wrote on Oct 15, 2007
-Mike
---
**sirmarcos** wrote on Oct 15, 2007
Thanks. There's an analogus problem in another routine:
if (tschop == FALSE && czr > 4.0) {
What should this be?
thanks,
phil </div> --- **Mike Fitzpatrick** wrote on Oct 15, 2007
if (!tschop[i] && czr[i] > 4.0) { -Mike
I have the some bad lines in the source code (the if DEBUG == YES lines anyway) that I compiled but I don't know why it's compiling for me without any trouble and not Phil. I can only assume compiler differences.
Are you unable to compile the rvsao without modifying it first as well Mike?
---
**JCab** wrote on Oct 15, 2007
Are you unable to compile the rvsao without modifying it first as well Mike?
I had this problem with rvsao, it turned out to be the g77 compiler (its being too finicky about the logicals). You can get around it by adding the "-fugly-logint" flag to your g77 compile statements. I tried to get clever (or stupid, you can decide) and decided to create an 'f77' script that when called (by very old FORTRAN makefiles, which don't know about g77) would issue this g77 command with the proper flag automatically. I posted my script to my blog in July. Its available at at:
http://iparrizar.mnstate.edu/~juan/urania/2007/07/19/f77-script-for-macos/
I hope this helps. I went with this solution because several of the SAO IRAF packages were giving me problems until I did this.
---
**Mike Fitzpatrick** wrote on Oct 15, 2007
http://iparrizar.mnstate.edu/~juan/urania/2007/07/19/f77-script-for-macos/
I hope this helps. I went with this solution because several of the SAO IRAF packages were giving me problems until I did this.
Thanks for the post about the needed compiler flag. FWIW if you use 'g77' all the time and need this flag it can be set for all compilations either in the user environment (e.g. your .cshrc file) using:
or for problematic packages you can edit the 'mkpkg.inc' file for the package (normally in the pkg$lib directory but in the case of RVSAO it's in the main rvsao$ dir) to add "-/fugly-int" to the 'XFLAGS' definition. The '/' tells the XC compiler to pass the flag thru to the underlying compiler unchanged, but note this sometimes causes problems or warning if say G77 knows the flag but GCC doesn't (i.e. the XFLAGS are passed to all sources being compiled, you'll need the XC_FFLAGS trick to pass only to fortran code).
-Mike
---
*Last post on Oct 15, 2007*
setenv XC_F77 g77
setenv XC_FFLAGS "-fugly-logint"
or for problematic packages you can edit the 'mkpkg.inc' file for the package (normally in the pkg$lib directory but in the case of RVSAO it's in the main rvsao$ dir) to add "-/fugly-int" to the 'XFLAGS' definition. The '/' tells the XC compiler to pass the flag thru to the underlying compiler unchanged, but note this sometimes causes problems or warning if say G77 knows the flag but GCC doesn't (i.e. the XFLAGS are passed to all sources being compiled, you'll need the XC_FFLAGS trick to pass only to fortran code).
-Mike