Help can not compile package with f77

[adameye]

I'm trying to compile a package on Ubuntu, errors:

f77 -fast -c -o contour2.o contour2.f
MAIN contour2:
sum:
ssort:
cc1: error: unrecognized command line option "-fast"
/usr/bin/f77: aborting compilation
make[1]: *** [contour2.o] Error 25
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make: *** [everything] Error 2

please help me, thanks

 

[D H]

cc1: error: unrecognized command line option "-fast"

What part of the bolded text don't you understand?

 

[adameye]

I don't know how to solve the problem, when I deleted -fast from the makefile, I got:


make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -c -o contour2.o contour2.f
MAIN contour2:
sum:
ssort:
f77 -o ../Bin/contour2 contour2.o
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make contour3
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -c -o contour3.o contour3.f
MAIN contour3:
sum:
ssort:
erfcc:
f77 -o ../Bin/contour3 contour3.o
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make contour6
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -c -o contour6.o contour6.f
MAIN contour6:
sum:
ssort:
erfcc:
f77 -o ../Bin/contour6 contour6.o
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make gsmooth
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -c -o gsmooth.o gsmooth.f
MAIN:
f77 -c -o src3ft.o src3ft.f
src3ft:
realfft:
cxfft3:
Warning on line 216: inconsistent calling sequences for cxfft3,
arg 1: here complex variable, previously real variable.
arg 6: here complex variable, previously real variable.
cfft99:
Warning on line 513: inconsistent calling sequences for cfft99,
arg 1: here real variable, previously complex variable.
arg 2: here real variable, previously complex variable.
cftfax:
fact:
cftrig:
vpassm:
/tmp/fort77-9102-1.c:353: error: conflicting types for ‘cxfft3_’
/tmp/fort77-9102-1.c:173: error: previous declaration of ‘cxfft3_’ was here
/tmp/fort77-9102-1.c:434: error: conflicting types for ‘cfft99_’
/tmp/fort77-9102-1.c:370: error: previous declaration of ‘cfft99_’ was here
/usr/bin/f77: aborting compilation
make[1]: *** [src3ft.o] Error 25
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make: *** [everything] Error 2


my makefile is:
BINDIR=../Bin
FC= f77
FLINK=f77
FFLAGS=
CC=cc
CLINK=cc
CFLAGS=-O
FLIB=
CLIB=

everything: Makefile
make contour2
make contour3
make contour6
make gsmooth
make cicden
make delrho
make multi
make divide
make rhostats
make mrhostats
make rmask
make poisson_den
make scalar

thebasics: Makefile
make contour3
make gsmooth
make multi
make divide
make scalar

OBJS1= contour2.o
contour2: $(OBJS1) Makefile
$(FLINK) $(FFLAGS) -o $(BINDIR)/contour2 $(OBJS1) $(FLIB)

OBJS2= contour3.o
contour3: $(OBJS2) Makefile
$(FLINK) $(FFLAGS) -o $(BINDIR)/contour3 $(OBJS2) $(FLIB)

OBJS3= gsmooth.o src3ft.o
gsmooth: $(OBJS3) Makefile
$(FLINK) $(FFLAGS) -o $(BINDIR)/gsmooth $(OBJS3) $(FLIB)

OBJS4= cicden.o
cicden: $(OBJS4) Makefile
$(FLINK) $(FFLAGS) -o $(BINDIR)/cicden $(OBJS4) $(FLIB)

OBJS5= delrho.o ftread.o ftwrite.o ssumc.o
delrho: $(OBJS5) Makefile
$(CLINK) $(CFLAGS) -o $(BINDIR)/delrho $(OBJS5) $(CLIB)

OBJS6= multi.o ftread.o ftwrite.o alloc.o
multi: $(OBJS6) Makefile
$(CLINK) $(CFLAGS) -o $(BINDIR)/multi $(OBJS6) $(CLIB)

OBJS7= divide.o ftread.o ftwrite.o alloc.o
divide: $(OBJS7) Makefile
$(CLINK) $(CFLAGS) -o $(BINDIR)/divide $(OBJS7) $(CLIB)

OBJS8= rhostats.o ftread.o ftwrite.o alloc.o
rhostats: $(OBJS8) Makefile
$(CLINK) $(CFLAGS) -o $(BINDIR)/rhostats $(OBJS8) $(CLIB)

OBJS9= mrhostats.o ftread.o ftwrite.o alloc.o
mrhostats: $(OBJS9) Makefile
$(CLINK) $(CFLAGS) -o $(BINDIR)/mrhostats $(OBJS9) $(CLIB)

OBJS10= rmask.o ftread.o ftwrite.o alloc.o
rmask: $(OBJS10) Makefile
$(CLINK) $(CFLAGS) -o $(BINDIR)/rmask $(OBJS10) $(CLIB)

OBJS11= poisson_den.o ranc.o alloc.o ftwrite.o
poisson_den: $(OBJS11) Makefile
$(CLINK) $(CFLAGS) -o $(BINDIR)/poisson_den $(OBJS11) $(CLIB)

OBJS12= scalar.o alloc.o ftread.o ftwrite.o
scalar: $(OBJS12) Makefile
$(CLINK) $(CFLAGS) -o $(BINDIR)/scalar $(OBJS12) $(CLIB)

OBJS13= contour6.o
contour6: $(OBJS13) Makefile
$(FLINK) $(FFLAGS) -o $(BINDIR)/contour6 $(OBJS13) $(FLIB)

I just don't know how to fix it! any help will be appreciated!

What part of the bolded text don't you understand?

 

[mathmate]

There are compilation errors which seem to indicate that your compiler accepts 6-character variable names (F77 standard) while the source code expects some other compilers that accept an extension (sometimes up to 32 characters).

It's time to check the source code package for the compatible operating systems and compilers, and see if your system or compiler is one of them. If not, expect to do some hands-on programming/modifications.

 

[adameye]

Thanks for your reply, but if you can tell me how to "check the source code package for the compatible operating systems and compilers", that will be awesome.
1,Does that mean I have to find other machines with different system?
2,I do not know how to select "complier", looks makefile has defined everything, so I should edit makefile?

There are compilation errors which seem to indicate that your compiler accepts 6-character variable names (F77 standard) while the source code expects some other compilers that accept an extension (sometimes up to 32 characters).

It's time to check the source code package for the compatible operating systems and compilers, and see if your system or compiler is one of them. If not, expect to do some hands-on programming/modifications.

 

[mathmate]

The source code package normally come with installation or compiling/linking instructions.
These instructions typically indicate the required machines, operating system, language and compiler. The internal settings are generally taken care of by the Makefile.

Very often, these instructions also indicate on which systems the source code has been successfully compiled, that doesn't mean that it will not compile correctly under other environments. It is possible that there are just minor adjustments to the code to be made, but that usually require understanding of the problem and the adjustments required, i.e. a little programming.

The fact that your Makefile contains a -fast parameter which your compiler does not understand seems to tell me that you may not be using a correct compiler.

My suggestion is to go back to the installation/compiling/linking instructions and find out what the acceptable environments are, and see if you can comply, within your limits of resources.

Another option is to search on the Internet to see if there are binary/executable versions of the code that runs on your platform... unless you need to modify the code for your own purposes.

 

[adameye]

thanks for your reply, I can not find information in my source package, I attached my package here, if anyone can look at it, that will be awesome, this package comes from david weinberg, who is one of the famousest astronomy scentists in the world now.

The source code package normally come with installation or compiling/linking instructions.
These instructions typically indicate the required machines, operating system, language and compiler. The internal settings are generally taken care of by the Makefile.

Very often, these instructions also indicate on which systems the source code has been successfully compiled, that doesn't mean that it will not compile correctly under other environments. It is possible that there are just minor adjustments to the code to be made, but that usually require understanding of the problem and the adjustments required, i.e. a little programming.

The fact that your Makefile contains a -fast parameter which your compiler does not understand seems to tell me that you may not be using a correct compiler.

My suggestion is to go back to the installation/compiling/linking instructions and find out what the acceptable environments are, and see if you can comply, within your limits of resources.

Another option is to search on the Internet to see if there are binary/executable versions of the code that runs on your platform... unless you need to modify the code for your own purposes.

 

[D H]

The code is broken. Look at the offending file. In the calls to cxfft3 in subroutine src3ft, the first and last arguments passed to cxfft3 are real*4 arrays. The function cxfft3 declares those arguments as complex arrays. How to fix it: Talk to the author.

 

[mathmate]

I agree with DH to discuss with the author. However, I believe the problem can be fixed by modifying the source code.

In my opinion, the author wanted to manipulate the real and complex components as real values in the calling program, while the called subroutine treats the same array as a complex array. Lines 89-98 give it away.

c---  Output : DATA contains Fourier components at grid points
c---                (n1/2,n2,n3); i.e. DATA(1,1,1) and DATA(2,1,1)
c---                are the real and complex components of the 1st
c---                (kx=ky=kz=0) Fourier component and so on.
c---                This means we use only the half plane kx >= 0
c---                for FFTs of a real array to save time and memory.
c---           SPEQ contains the Nyquist frequency values of kx 
c---                frequency component; i.e. SPEQ(1,1,1) and SPEQ(2,1,1)
c---                are the real and complex components of the component
c---                with kx=n1/2, ky=kz=0 and so on.

In the old days, this practice was very common, and compilers blindly linked them together, so the source code package WAS correct. With modern linkers(*), more checking is done, and so this practice was disallowed.

How do we fix it? ...By using EQUIVALENCE. Fortran allows users to share memory by calling the same location by different names, in much the same way as "union" in the C-language.

Here is a very simple example of how equivalence is used:

      REAL*4 A(2,4)
      COMPLEX*8 C(4)
      EQUIVALENCE(A,C)
      A(1,3)=2.0
      A(2,3)=1.0
      PRINT *,REAL(C(3)),AIMAG(C(3))
      STOP
      END

You can apply the idea to the calling program by declaring COMPLEX arrays with the first dimension half of that of the equivalent REAL array. Do not forget to declare EQUIVALENCE between the REAL and COMPLEX arrays, otherwise they will be simply two independent ones. The subroutine call will be modified to use the complex arrays instead of the real arrays. This way, the linker(*) will realize that the sharing of memory is intended.

Whether you are successful with this attempt or not, I suggest you still inform the author of what you have done. If this is done correctly, other users will benefit from your changes. If not, perhaps he will already have a fix for you.

His e-mail address is:
dhw@astronomy.ohio-state.edu

* edited 09:33 PM (UT)

 

[adameye]

thanks for your reply, Actually David Weinberg gave me this package a few weeks ago, and when I told him I have problem to install, he told me he can not help me for this "compiler" issue, so I came to this forum to seek help...

I really do not want to bother him again for this "off-research" issue. I will try to use your "EQUIVALENCE" even I never use fortran..


Thanks again

I agree with DH to discuss with the author. However, I believe the problem can be fixed by modifying the source code.

In my opinion, the author wanted to manipulate the real and complex components as real values in the calling program, while the called subroutine treats the same array as a complex array. Lines 89-98 give it away.

c---  Output : DATA contains Fourier components at grid points
c---                (n1/2,n2,n3); i.e. DATA(1,1,1) and DATA(2,1,1)
c---                are the real and complex components of the 1st
c---                (kx=ky=kz=0) Fourier component and so on.
c---                This means we use only the half plane kx >= 0
c---                for FFTs of a real array to save time and memory.
c---           SPEQ contains the Nyquist frequency values of kx 
c---                frequency component; i.e. SPEQ(1,1,1) and SPEQ(2,1,1)
c---                are the real and complex components of the component
c---                with kx=n1/2, ky=kz=0 and so on.

In the old days, this practice was very common, and compilers blindly linked them together, so the source code package WAS correct. With modern linkers(*), more checking is done, and so this practice was disallowed.

How do we fix it? ...By using EQUIVALENCE. Fortran allows users to share memory by calling the same location by different names, in much the same way as "union" in the C-language.

Here is a very simple example of how equivalence is used:

      REAL*4 A(2,4)
      COMPLEX*8 C(4)
      EQUIVALENCE(A,C)
      A(1,3)=2.0
      A(2,3)=1.0
      PRINT *,REAL(C(3)),AIMAG(C(3))
      STOP
      END

You can apply the idea to the calling program by declaring COMPLEX arrays with the first dimension half of that of the equivalent REAL array. Do not forget to declare EQUIVALENCE between the REAL and COMPLEX arrays, otherwise they will be simply two independent ones. The subroutine call will be modified to use the complex arrays instead of the real arrays. This way, the linker(*) will realize that the sharing of memory is intended.

Whether you are successful with this attempt or not, I suggest you still inform the author of what you have done. If this is done correctly, other users will benefit from your changes. If not, perhaps he will already have a fix for you.

His e-mail address is:
dhw@astronomy.ohio-state.edu

* edited 09:33 PM (UT)

 

[mathmate]

Actually, I have written to him about the -fast option, and he replied to me that it probably was run on the SGI unix system.
I followed up with the question of equivalence, and hope he will give me a reply soon. On the other hand, you can go ahead and give it a try.
Unfortunately my F77 compiler cannot accept the large size of memory requested in the program, so I cannot check if it works. If you'd like, I can make a suggestion and you can run the Makefile to see if it works.
Will get back to you soon.

 

[mathmate]

Here are my proposed changes:

As of line 114, make the changes in bold, the old call to cxfft has to be commented as shown:

c---  memory than the array size, which is crucial to n-body work.

      double precision wr,wi,wpr,wtemp,theta
      real*4 data(n1,n2,n3),speq(2,n2,n3)
      COMPLEX*8 CDATA(n1/2,n2,n3),CSPEQ(1,n2,n3)
      EQUIVALENCE (data, CDATA), (speq, CSPEQ)
      ip1= 1
      im1= 1
      c1 = 0.5
      c2 = -0.5*isign
      theta = 6.28318530717959d0/dble(isign*n1)
      wpr = -2.d0*dsin(0.5d0*theta)**2
      wpi = dsin(theta)
c---  Forward Transform
      if(isign.eq.1)then
C      call cxfft3(data,n1/2,n2,n3,isign,speq)
      call cxfft3(CDATA,n1/2,n2,n3,isign,CSPEQ)
      do 12 i3=1,n3
      do 11 i2=1,n2

Make the same change to line 201, call cxfft3(CDATA...) as the lines above.
Good luck.

 

[adameye]

thanks for your help!
this is the result, looks I still have problem.

make contour2
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -o ../Bin/contour2 contour2.o
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make contour3
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -o ../Bin/contour3 contour3.o
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make contour6
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -o ../Bin/contour6 contour6.o
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make gsmooth
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -c -o src3ft.o src3ft.f
src3ft:
realfft:

Error processing equivalences before line 121: Declaration error for data: adjustable in equivalence
Error processing equivalences before line 121: Declaration error for speq: adjustable in equivalence
Error on line 207: nondigit in statement label field " end"
Error on line 207: unclassifiable statement (starts "if")
Error on line 209: DO loop or BLOCK IF not closed
cxfft3:
Warning on line 221: inconsistent calling sequences for cxfft3,
arg 1: here complex variable, previously real variable.
arg 6: here complex variable, previously real variable.
cfft99:
Warning on line 518: inconsistent calling sequences for cfft99,
arg 1: here real variable, previously complex variable.
arg 2: here real variable, previously complex variable.
cftfax:
fact:
cftrig:
vpassm:
/usr/bin/f77: aborting compilation
make[1]: *** [src3ft.o] Error 25
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make: *** [everything] Error 2

Here are my proposed changes:

As of line 114, make the changes in bold, the old call to cxfft has to be commented as shown:

c---  memory than the array size, which is crucial to n-body work.

      double precision wr,wi,wpr,wtemp,theta
      real*4 data(n1,n2,n3),speq(2,n2,n3)
      COMPLEX*8 CDATA(n1/2,n2,n3),CSPEQ(1,n2,n3)
      EQUIVALENCE (data, CDATA), (speq, CSPEQ)
      ip1= 1
      im1= 1
      c1 = 0.5
      c2 = -0.5*isign
      theta = 6.28318530717959d0/dble(isign*n1)
      wpr = -2.d0*dsin(0.5d0*theta)**2
      wpi = dsin(theta)
c---  Forward Transform
      if(isign.eq.1)then
C      call cxfft3(data,n1/2,n2,n3,isign,speq)
      call cxfft3(CDATA,n1/2,n2,n3,isign,CSPEQ)
      do 12 i3=1,n3
      do 11 i2=1,n2

Make the same change to line 201, call cxfft3(CDATA...) as the lines above.
Good luck.

 

[mathmate]

Could you post the source program that you have changed? It seems that there are unexpected errors.

By the way, I have a reply from Professor Weinberg that encourages us to try the EQUIVALENCE fix. He added that the part where we have a problem is in one of the supplementary programs which was not writtem by himself. He has included a different version of src3ft2.f that is "is less flexible but may compile more easily".

I believe the best bet for now is to fix the problem using equivalence. We'll see what to do if we encounter problems.

The equivalence statement may do the trick, but I'm not certain.I think you will just have to try it and see whether it givesreasonable results, since this is not a problem I encountered myself.
This call arises in one of the "supplementary" programs I provided rather than contour itself -- albeit, a supplementary program that will be very useful if you can get it working.The version of the "src3ft2.f" that is included with the package is not one that I put together myself; if it is causing difficulty, you could try the version attached here, which is less flexible but may compile more easily.
Good luck.
David

Hope to hear from you soon.

P.S. I enclose herewith the version of src3ft2.f from Professor Weinberg.

 

[adameye]

I am very glad to see Prof Weinberg joined in this issue...

1,
from line 116,
was:
double precision wr,wi,wpr,wtemp,theta
real*4 data(n1,n2,n3),speq(2,n2,n3)
now:
double precision wr,wi,wpr,wtemp,theta
real*4 data(n1,n2,n3),speq(2,n2,n3)
COMPLEX*8 CDATA(n1/2,n2,n3),CSPEQ(1,n2,n3)
EQUIVALENCE (data, CDATA), (speq, CSPEQ)

from line 130,
was:
call cxfft3(data,n1/2,n2,n3,isign,speq)
now:
call cxfft3(CDATA,n1/2,n2,n3,isign,CSPEQ)

from line 205,
was:
call cxfft3(data,n1/2,n2,n3,isign,speq)
now:
call cxfft3(CDATA,n1/2,n2,n3,isign,CSPEQ)

I tried the new src3ft2.f, changed its name to src3ft.f, then I got the following error message:
make contour2
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
f77 -o ../Bin/contour2 contour2.o
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make contour3
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
f77 -o ../Bin/contour3 contour3.o
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make contour6
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
f77 -o ../Bin/contour6 contour6.o
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make gsmooth
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
f77 -o ../Bin/gsmooth gsmooth.o src3ft.o
gsmooth.o: In function `MAIN__':
fort77-23718-1.c:(.text+0x3b2): undefined reference to `src3ft_'
fort77-23718-1.c:(.text+0x640): undefined reference to `src3ft_'
collect2: ld returned 1 exit status
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make cicden
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
f77 -o ../Bin/cicden cicden.o
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make delrho
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
cc -O -o ../Bin/delrho delrho.o ftread.o ftwrite.o ssumc.o
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make multi
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
cc -O -o ../Bin/multi multi.o ftread.o ftwrite.o alloc.o
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make divide
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
cc -O -o ../Bin/divide divide.o ftread.o ftwrite.o alloc.o
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make rhostats
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
cc -O -o ../Bin/rhostats rhostats.o ftread.o ftwrite.o alloc.o
rhostats.o: In function `main':
rhostats.c:(.text+0x1d1): undefined reference to `sqrtf'
collect2: ld returned 1 exit status
make[1]: *** [rhostats] Error 1
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make: *** [everything] Error 2

Could you post the source program that you have changed? It seems that there are unexpected errors.

By the way, I have a reply from Professor Weinberg that encourages us to try the EQUIVALENCE fix. He added that the part where we have a problem is in one of the supplementary programs which was not writtem by himself. He has included a different version of src3ft2.f that is "is less flexible but may compile more easily".

I believe the best bet for now is to fix the problem using equivalence. We'll see what to do if we encounter problems.



Hope to hear from you soon.

P.S. I enclose herewith the version of src3ft2.f from Professor Weinberg.

 

[mathmate]

double precision wr,wi,wpr,wtemp,theta
real*4 data(n1,n2,n3),speq(2,n2,n3)
COMPLEX*8 CDATA(n1/2,n2,n3),CSPEQ(1,n2,n3)
EQUIVALENCE (data, CDATA), (speq, CSPEQ)

from line 130,
was:
call cxfft3(data,n1/2,n2,n3,isign,speq)
now:
call cxfft3(CDATA,n1/2,n2,n3,isign,CSPEQ)

from line 205,
was:
call cxfft3(data,n1/2,n2,n3,isign,speq)
now:
call cxfft3(CDATA,n1/2,n2,n3,isign,CSPEQ)

Does the above code still give the following error messages. If not, could you send me the new error messages, if any?

Error processing equivalences before line 121: Declaration error for data: adjustable in equivalence
Error processing equivalences before line 121: Declaration error for speq: adjustable in equivalence
Error on line 207: nondigit in statement label field " end"
Error on line 207: unclassifiable statement (starts "if")
Error on line 209: DO loop or BLOCK IF not closed
cxfft3:
Warning on line 221: inconsistent calling sequences for cxfft3,
arg 1: here complex variable, previously real variable.
arg 6: here complex variable, previously real variable.
cfft99:
Warning on line 518: inconsistent calling sequences for cfft99,
arg 1: here real variable, previously complex variable.
arg 2: here real variable, previously complex variable.

I have taken a closer look at the calling sequence. Unfortunately x and speq have been passed on as formal parameters with variable dimensioning, it may be possible to require other minor modifications that relate to x(*). It may work out on your compiler though, that is why I need the latest messages that correspond to the code in order to find the next step.

I would hold off the trial on the new version of scrfft3.f for now. The sqrtf() not found error can easily be solved by replacing sqrtf() by sqrt(). There used to be a time when the library functions were all suffixed with the letter f. It was subsequently removed.

 

[adameye]

with the corrected src3ft.f, I got the following error message:
make contour2
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -o ../Bin/contour2 contour2.o
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make contour3
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -o ../Bin/contour3 contour3.o
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make contour6
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -o ../Bin/contour6 contour6.o
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make gsmooth
make[1]: Entering directory `/home/wyf/Desktop/Package/Source'
f77 -c -o src3ft.o src3ft.f
src3ft:
realfft:
Error processing equivalences before line 121: Declaration error for data: adjustable in equivalence
Error processing equivalences before line 121: Declaration error for speq: adjustable in equivalence
Error on line 207: nondigit in statement label field " end"
Error on line 207: unclassifiable statement (starts "if")
Error on line 209: DO loop or BLOCK IF not closed
cxfft3:
Warning on line 221: inconsistent calling sequences for cxfft3,
arg 1: here complex variable, previously real variable.
arg 6: here complex variable, previously real variable.
cfft99:
Warning on line 518: inconsistent calling sequences for cfft99,
arg 1: here real variable, previously complex variable.
arg 2: here real variable, previously complex variable.
cftfax:
fact:
cftrig:
vpassm:
/usr/bin/f77: aborting compilation
make[1]: *** [src3ft.o] Error 25
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make: *** [everything] Error 2

double precision wr,wi,wpr,wtemp,theta
real*4 data(n1,n2,n3),speq(2,n2,n3)
COMPLEX*8 CDATA(n1/2,n2,n3),CSPEQ(1,n2,n3)
EQUIVALENCE (data, CDATA), (speq, CSPEQ)

from line 130,
was:
call cxfft3(data,n1/2,n2,n3,isign,speq)
now:
call cxfft3(CDATA,n1/2,n2,n3,isign,CSPEQ)

from line 205,
was:
call cxfft3(data,n1/2,n2,n3,isign,speq)
now:
call cxfft3(CDATA,n1/2,n2,n3,isign,CSPEQ)

Does the above code still give the following error messages. If not, could you send me the new error messages, if any?


I have taken a closer look at the calling sequence. Unfortunately x and speq have been passed on as formal parameters with variable dimensioning, it may be possible to require other minor modifications that relate to x(*). It may work out on your compiler though, that is why I need the latest messages that correspond to the code in order to find the next step.

I would hold off the trial on the new version of scrfft3.f for now. The sqrtf() not found error can easily be solved by replacing sqrtf() by sqrt(). There used to be a time when the library functions were all suffixed with the letter f. It was subsequently removed.

 

[mathmate]

It may be simpler for me if you could send me the "corrected" version of the src3ft.f, the version that contains the equivalence modifications. It will have to be zipped because I don't think .f extension will be allowed here. I can then read the line numbers with the error messages, and attempt modifications as required. Since I do not yet have the Linux compiler, it will take a couple of attempts.

 

[adameye]

please see attachment, I did not compress, and just changed the name( src3ft.f to src3ft.zip), you need to change the name back, thank you very much

It may be simpler for me if you could send me the "corrected" version of the src3ft.f, the version that contains the equivalence modifications. It will have to be zipped because I don't think .f extension will be allowed here. I can then read the line numbers with the error messages, and attempt modifications as required. Since I do not yet have the Linux compiler, it will take a couple of attempts.

 

[mathmate]

Sorry that it took a while to get back to you.
I finally installed g77 on my computer, but it confirms that it does not like the equivalence statement as I have suggested. On the other hand, it compiles the original file as is without any hitch.
I was wondering, on the Linux system that you use, do you have g77 available?
Could you try to modify the first few lines of the Makefile to change f77 to g77, or whichever command required to run g77 on your computer?

 

[adameye]

when I use the new version src3ft.f (Weinberg sent to you), I got the following errors after changing f77 to g77:
make contour2
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
g77 -o ../Bin/contour2 contour2.o
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make contour3
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
g77 -o ../Bin/contour3 contour3.o
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make contour6
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
g77 -o ../Bin/contour6 contour6.o
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make gsmooth
make[1]: Entering directory `/home/wyf/Desktop/backup/Package/Source'
g77 -o ../Bin/gsmooth gsmooth.o src3ft.o
gsmooth.o: In function `MAIN__':
fort77-23718-1.c:(.text+0x3b2): undefined reference to `src3ft_'
fort77-23718-1.c:(.text+0x640): undefined reference to `src3ft_'
collect2: ld returned 1 exit status
make[1]: *** [gsmooth] Error 1
make[1]: Leaving directory `/home/wyf/Desktop/backup/Package/Source'
make: *** [everything] Error 2

When I try the old version src3ft.f (we use equivalence statement), I got the following errors:
...
...
Label 130 already defined at (1) when redefined at (2)
src3ft.f:586:
140 continue
1
src3ft.f:877: (continued):
do 140 l=1,la
2
DO-statement reference to label at (2) follows its definition at (1)
src3ft.f:586:
140 continue
1
src3ft.f:905: (continued):
140 continue
2
Label 140 already defined at (1) when redefined at (2)
src3ft.f:204:
if(isign.eq.-1)then
1
src3ft.f:978: (continued):
end
2
Statement at (2) invalid in context established by statement at (1)
src3ft.f:204:
if(isign.eq.-1)then
^
End of source file before end of block started at (^)
src3ft.f:43: warning:
call realfft(x,l1,l2,l3,speq,isign)
1
src3ft.f:82: (continued):
subroutine realfft(data,n1,n2,n3,speq,isign)
2
Argument #1 (named `data') of `realfft' is one type at (2) but is some other type at (1) [info -f g77 M GLOBALS]
src3ft.f:43: warning:
call realfft(x,l1,l2,l3,speq,isign)
1
src3ft.f:82: (continued):
subroutine realfft(data,n1,n2,n3,speq,isign)
2
Argument #5 (named `speq') of `realfft' is one type at (2) but is some other type at (1) [info -f g77 M GLOBALS]
make[1]: *** [src3ft.o] Error 1
make[1]: Leaving directory `/home/wyf/Desktop/Package/Source'
make: *** [everything] Error 2

Sorry that it took a while to get back to you.
I finally installed g77 on my computer, but it confirms that it does not like the equivalence statement as I have suggested. On the other hand, it compiles the original file as is without any hitch.
I was wondering, on the Linux system that you use, do you have g77 available?
Could you try to modify the first few lines of the Makefile to change f77 to g77, or whichever command required to run g77 on your computer?

 

[adameye]

my computer system is Ubuntu 8.10 the intrepid lbex, my g77 is a kind gcc-3.4.6 (I use "man g77" and find gcc-3.4.6 in the end of "man g77"), looks I have another command "g77-3.4" except for g77, but that does not make difference for this issue,

Sorry that it took a while to get back to you.
I finally installed g77 on my computer, but it confirms that it does not like the equivalence statement as I have suggested. On the other hand, it compiles the original file as is without any hitch.
I was wondering, on the Linux system that you use, do you have g77 available?
Could you try to modify the first few lines of the Makefile to change f77 to g77, or whichever command required to run g77 on your computer?

 

[mathmate]

Sorry Adameye. I tried in vain compiling with my g77. I got other errors. It appears to me the without installing Linux, I am not able to reproduce the make sequence required to link the program, or reproduce your problem in order to fix it.
I have a medium plan to install Linux on a separate partition on my current computer. I will get back to this question when the time comes.
On the other hand, the author has mentioned that the program that gives trouble is a anciliary program which is not a requirement. So I hope you are able to function with what has been accomplished.

 

[adameye]

thanks for your reply, I'm thinking maybe it is an issue of 64-bit & 32-bit problem?
I will try to find a different bit computer and check it...

Sorry Adameye. I tried in vain compiling with my g77. I got other errors. It appears to me the without installing Linux, I am not able to reproduce the make sequence required to link the program, or reproduce your problem in order to fix it.
I have a medium plan to install Linux on a separate partition on my current computer. I will get back to this question when the time comes.
On the other hand, the author has mentioned that the program that gives trouble is a anciliary program which is not a requirement. So I hope you are able to function with what has been accomplished.

 

[adameye]

updated process:
Finally Prof Weinberg contacted the student who wrote the program, now he told me I need to install a library called "libfutil.a". http://www.physics.ohio-state.edu/~orban/lib_test.tar.gz
I'm trying to figure out how to install this package, looks I do not have ifort command even I installed it. I posted my questions on http://ubuntuforums.org/showthread.php?t=1182156&highlight=ifort

Sorry Adameye. I tried in vain compiling with my g77. I got other errors. It appears to me the without installing Linux, I am not able to reproduce the make sequence required to link the program, or reproduce your problem in order to fix it.
I have a medium plan to install Linux on a separate partition on my current computer. I will get back to this question when the time comes.
On the other hand, the author has mentioned that the program that gives trouble is a anciliary program which is not a requirement. So I hope you are able to function with what has been accomplished.

 

[mathmate]

In:

PATH="/opt/intel/Compiler/11.0/083/bi/ia32n:$PATH"
export PATH

According to the locate command's output, shouldn't it be:

PATH="/opt/intel/Compiler/11.0/083/bi[b]n[/b]/ia32n:$PATH"
export PATH

Also, you may have an error in the startup file, probably called profile.sh in your main user directory. If you do the command:

ls -la

you may see it. Most of the time it is hidden.
check what the installation has added to it and see if the commands are correct, related to ia32.

 

[adameye]

oh, I made a small mistake when I copied .bashrc file to forum, that is not a reason why I can not use ifort command.

I can't find the file profile.sh you mentioned, looks there is no starup file on Ubuntu 8.10?

In:

PATH="/opt/intel/Compiler/11.0/083/bi/ia32n:$PATH"
export PATH

According to the locate command's output, shouldn't it be:

PATH="/opt/intel/Compiler/11.0/083/bi[b]n[/b]/ia32n:$PATH"
export PATH

Also, you may have an error in the startup file, probably called profile.sh in your main user directory. If you do the command:

ls -la

you may see it. Most of the time it is hidden.
check what the installation has added to it and see if the commands are correct, related to ia32.

 

[mathmate]

The start-up file may not be called profile.sh, depending on the kernel you are using (bash?).

It may also reside in /etc. The path would have been added on by the installation program.

Looking back at your information, I find that the file is here:
/opt/intel/Compiler/11.0/083/bin/ia32/ifort
while your path adds the following path with the two commands:

PATH="/opt/intel/Compiler/11.0/083/bin/ia32:$PATH"
export PATH

Could you manually execute these two commands and try again?
If it does not work, perhaps ifort is not an executable.
You can check this by running
/opt/intel/Compiler/11.0/083/bin/ia32/ifort
and see if you have any response.
(Note: danger is if ifort is not an executable, anything can happen, check your reference manual or installation manual before trying).

The problem could also lie in the error message for unknown switch. Check the installation manual to see if UBUNTU is a known operating system.

 

[adameye]

my kernel:
wyf@wyf-desktop:~$ uname -a
Linux wyf-desktop 2.6.27-11-generic #1 SMP Wed Apr 1 20:57:48 UTC 2009 i686 GNU/Linux

I tried ifort:
wyf@wyf-desktop:~$ /opt/intel/Compiler/11.0/083/bin/ia32/ifort
ifort: command line error: no files specified; for help type "ifort -help"

I tried to add the following sentence into .bashrc file and remove all things I added before, it works!
alias ifort=/opt/intel/Compiler/11.0/083/bin/ia32/ifortbut when I tried to install the package which require "ifort", I got :
wyf@wyf-desktop:~/software$ make futil
ifort -ftz -mp1 -posixlib -Vaxlib -c gasdev.for ran1.f src3ft.f snrsq.f scopy.f sscal.f && ar -rlv \
libfutil.a gasdev.o ran1.o src3ft.o snrsq.o scopy.o sscal.o
ifort: command line warning #10156: ignoring option '-p'; no argument required
src3ft.f(656): (col. 10) remark: LOOP WAS VECTORIZED.
src3ft.f(599): (col. 12) remark: LOOP WAS VECTORIZED.
src3ft.f(41): (col. 5) remark: LOOP WAS VECTORIZED.
src3ft.f(66): (col. 5) remark: LOOP WAS VECTORIZED.
src3ft.f(145): (col. 10) remark: LOOP WAS VECTORIZED.
src3ft.f(228): (col. 16) remark: LOOP WAS VECTORIZED.
src3ft.f(229): (col. 16) remark: LOOP WAS VECTORIZED.
src3ft.f(230): (col. 16) remark: LOOP WAS VECTORIZED.
snrsq.f(10): (col. 10) remark: LOOP WAS VECTORIZED.
r - gasdev.o
r - ran1.o
r - src3ft.o
r - snrsq.o
r - scopy.o
r - sscal.o

looks installation fail?

The start-up file may not be called profile.sh, depending on the kernel you are using (bash?).

It may also reside in /etc. The path would have been added on by the installation program.

Looking back at your information, I find that the file is here:
/opt/intel/Compiler/11.0/083/bin/ia32/ifort
while your path adds the following path with the two commands:

PATH="/opt/intel/Compiler/11.0/083/bin/ia32:$PATH"
export PATH

Could you manually execute these two commands and try again?
If it does not work, perhaps ifort is not an executable.
You can check this by running
/opt/intel/Compiler/11.0/083/bin/ia32/ifort
and see if you have any response.
(Note: danger is if ifort is not an executable, anything can happen, check your reference manual or installation manual before trying).

The problem could also lie in the error message for unknown switch. Check the installation manual to see if UBUNTU is a known operating system.

 

[adameye]

I think I have ifort command now

wyf@wyf-desktop:~/weinberg_genus/Package/Source$ if
if ifconfig ifdown ifort ifup

but when I try to complie package:

wyf@wyf-desktop:~/weinberg_genus/Package/Source$ make everything
make contour2
make[1]: Entering directory `/home/wyf/weinberg_genus/Package/Source'
ifort -fast -c -o contour2.o contour2.f
make[1]: ifort: Command not found
make[1]: *** [contour2.o] Error 127
make[1]: Leaving directory `/home/wyf/weinberg_genus/Package/Source'
make: *** [everything] Error 2

totally confused, looks "alias ifort=/opt/intel/Compiler/11.0/083/bin/ia32/ifort" in .bashrc file is not enough for installing a package, but enough for executing a command in a terminal?

my kernel:
wyf@wyf-desktop:~$ uname -a
Linux wyf-desktop 2.6.27-11-generic #1 SMP Wed Apr 1 20:57:48 UTC 2009 i686 GNU/Linux

I tried ifort:
wyf@wyf-desktop:~$ /opt/intel/Compiler/11.0/083/bin/ia32/ifort
ifort: command line error: no files specified; for help type "ifort -help"

I tried to add the following sentence into .bashrc file and remove all things I added before, it works!
alias ifort=/opt/intel/Compiler/11.0/083/bin/ia32/ifort


but when I tried to install the package which require "ifort", I got :
wyf@wyf-desktop:~/software$ make futil
ifort -ftz -mp1 -posixlib -Vaxlib -c gasdev.for ran1.f src3ft.f snrsq.f scopy.f sscal.f && ar -rlv \
libfutil.a gasdev.o ran1.o src3ft.o snrsq.o scopy.o sscal.o
ifort: command line warning #10156: ignoring option '-p'; no argument required
src3ft.f(656): (col. 10) remark: LOOP WAS VECTORIZED.
src3ft.f(599): (col. 12) remark: LOOP WAS VECTORIZED.
src3ft.f(41): (col. 5) remark: LOOP WAS VECTORIZED.
src3ft.f(66): (col. 5) remark: LOOP WAS VECTORIZED.
src3ft.f(145): (col. 10) remark: LOOP WAS VECTORIZED.
src3ft.f(228): (col. 16) remark: LOOP WAS VECTORIZED.
src3ft.f(229): (col. 16) remark: LOOP WAS VECTORIZED.
src3ft.f(230): (col. 16) remark: LOOP WAS VECTORIZED.
snrsq.f(10): (col. 10) remark: LOOP WAS VECTORIZED.
r - gasdev.o
r - ran1.o
r - src3ft.o
r - snrsq.o
r - scopy.o
r - sscal.o

looks installation fail?