fnddr@acad3.alaska.edu (Rice Don D) (01/24/91)
A couple of cc/f77 problems have turned up (Ultrix 4.0/DS5000/Fortran 2.1). The first: > cc -c some.c libmld: Internal: st_pdn_idn: idn (268584352) less than 0 or greater than max (94) Here some.c is a numerical routine said to have run just fine in Vax C. It isn't my routine, but I don't see anything obviously wrong with it. Any idea what this curious error message signifies? Second, when trying to combine a main program written in C with a subroutine written in Fortran, the Fortran built-in functions aren't found: > cc -o prog main.c fortsub.o -lF77 -lU77 -lI77 -lm ld: Undefined: sinf cosf sqrtf I can't find anything in the Fortran manual that explains this. I poked around in the libraries looking for the *f symbols but didn't find them. The above command came from the Fortran manual, but I've found enough mistakes in the manual that I wouldn't be surprised if something is missing here, too. Thanks, Don Rice Internet: ddr@flux.gi.alaska.edu Geophysical Institute E-mail: fnddr@alaska.bitnet University of Alaska Phone: (907) 474-7569 Fairbanks, AK 99775 Loran: 64.86N 212.16E
farrell@tioga.Stanford.EDU (Phil Farrell) (01/25/91)
In article <1991Jan24.001055.3069@ims.alaska.edu> Don Rice (fnddr@acad3.alaska.edu) writes: >A couple of cc/f77 problems have turned up (Ultrix 4.0/DS5000/Fortran 2.1).... >... when trying to combine a main program written in C with a subroutine >written in Fortran, the Fortran built-in functions aren't found: > > cc -o prog main.c fortsub.o -lF77 -lU77 -lI77 -lm > ld: > Undefined: > sinf > cosf > sqrtf Is the C compiler even finding the libraries? As installed, Fortran 2.1 libraries are in /usr/lib/cmplrs/f77, but the C compiler looks for those -lF77 etc directives in /usr/lib. I created symbolic links for libF77.a, libI77.a, and libU77.a from /usr/lib/cmplrs/f77 to /usr/lib on my system to address this problem. Secondly, you realize that the linker only searches a library once for any references on its current "unresolved" list. If a routine from one library calls one from another library that has already been searched, that will created an undefined reference. You might play with the order of libraries on your command line, or even add another -l command at the end to search the library a second time. -Phil Farrell, Computer Systems Manager Stanford University School of Earth Sciences farrell@pangea.stanford.edu
caroline@pangea.Stanford.EDU (Caroline Lambert) (01/25/91)
In article <1991Jan24.194343.5054@morrow.stanford.edu> farrell@tioga.Stanford.EDU (Phil Farrell) writes: >In article <1991Jan24.001055.3069@ims.alaska.edu> >Don Rice (fnddr@acad3.alaska.edu) writes: >>A couple of cc/f77 problems have turned up (Ultrix 4.0/DS5000/Fortran 2.1).... >>... when trying to combine a main program written in C with a subroutine >>written in Fortran, the Fortran built-in functions aren't found: >> > cc -o prog main.c fortsub.o -lF77 -lU77 -lI77 -lm >> ld: >> Undefined: >> sinf >> cosf >> sqrtf > >Is the C compiler even finding the libraries? As installed, Fortran 2.1 >libraries are in /usr/lib/cmplrs/f77, but the C compiler looks for >those -lF77 etc directives in /usr/lib. I created symbolic links >for libF77.a, libI77.a, and libU77.a from /usr/lib/cmplrs/f77 to /usr/lib >on my system to address this problem. > >Secondly, you realize that the linker only searches a library once for >any references on its current "unresolved" list. If a routine from one >library calls one from another library that has already been searched, >that will created an undefined reference. You might play with the >order of libraries on your command line, or even add another -l command >at the end to search the library a second time. > I have the same problem. I have compiled my program on Phil's machine and it gives the same error, so linking the libraries doesn't work. I've already tried every conceivable order for linking the libraries and that doesn't work. What I did find, though, is the following: somewhere in my FORTRAN subroutine I have some statements like these: real a, b a = sin(b) The problem is that sin is a double precision function, and a and b are single precision. This code does work: double precision a, b a = sin(b) This works too: real a,b a = sngl(sin(dble(b))) If anyone knows why C/f77 with f772.1 complains about this mixture of single precision arguments to double precision functions, I'd like to know, since I'm having a miserable time porting some software to our DEC5000 machine with f772.1 which works fine on a DEC3100 with f771.3, and every other machine I have access to. -- Caroline Lambert Dept. of Geophysics Stanford University caroline@pangea.Stanford.EDU standard disclaimer
fnddr@acad3.alaska.edu (Rice Don D) (01/25/91)
In article <1991Jan24.203050.6702@morrow.stanford.edu>, caroline@pangea.Stanford.EDU (Caroline Lambert) writes... >In article <1991Jan24.194343.5054@morrow.stanford.edu> farrell@tioga.Stanford.EDU (Phil Farrell) writes: >>In article <1991Jan24.001055.3069@ims.alaska.edu> >>Don Rice (fnddr@acad3.alaska.edu) writes: >>>A couple of cc/f77 problems have turned up (Ultrix 4.0/DS5000/Fortran 2.1).... >>>... when trying to combine a main program written in C with a subroutine >>>written in Fortran, the Fortran built-in functions aren't found: >>> > cc -o prog main.c fortsub.o -lF77 -lU77 -lI77 -lm >>> ld: >>> Undefined: >>> sinf >>> cosf >>> sqrtf >> >>Is the C compiler even finding the libraries? As installed, Fortran 2.1 >>libraries are in /usr/lib/cmplrs/f77, but the C compiler looks for >>those -lF77 etc directives in /usr/lib. I created symbolic links >>for libF77.a, libI77.a, and libU77.a from /usr/lib/cmplrs/f77 to /usr/lib >>on my system to address this problem. I'd wondered about that, so I substituted a bogus library name in the cc command and it complained immediately. Omitting any of the libraries causes the number of undefined symbols to increase enormously. One possible problem: some libraries in /usr/lib are links to /usr/lib/cmplrs/cc2.0, while libraries in /usr/lib/cmplrs/f772.1 point into /usr/lib/cmplrs/cc2.1. Having a mix of 2.0 and 2.1 libraries sounds like bad news to me. >>Secondly, you realize that the linker only searches a library once for >>any references on its current "unresolved" list. If a routine from one >>library calls one from another library that has already been searched, >>that will created an undefined reference. You might play with the >>order of libraries on your command line, or even add another -l command >>at the end to search the library a second time. Doesn't seem to matter...we've tried various combinations and permutations. >I have the same problem. I have compiled my program on Phil's machine >and it gives the same error, so linking the libraries doesn't work. >I've already tried every conceivable order for linking the libraries >and that doesn't work. > >What I did find, though, is the following: somewhere in my FORTRAN >subroutine I have some statements like these: > > real a, b > a = sin(b) > >The problem is that sin is a double precision function, and a and b >are single precision. This code does work: > > double precision a, b > a = sin(b) > Using double precision arguments causes f77 to call the double precision version of the generic sin. In our program, it is all single precision and sin is turned into sinf. Changing it to use double precision functions does indeed solve the problem. I'm not real wild about changing all the single precision stuff to double precision though. We found that we can get the whole mess to link in single precision by doing this: cc -c main.c f77 -o prog main.o sub.o -lF77 -lI77 -lm I had some reservations about using f77 with a C main program, but it seems to work. Yuk. Something is broken here, even if it is only the Fortran documentation. In the process of fooling with this, I also found an apparent f77 compiler bug involving nested DO loops that didn't go away when optimization was turned off. There are certainly plenty of reasons to look forward to a new version of Fortran... Don Rice Internet: ddr@flux.gi.alaska.edu Geophysical Institute E-mail: fnddr@alaska.bitnet University of Alaska Phone: (907) 474-7569 Fairbanks, AK 99775 Loran: 64.86N 212.16E
daniels@bigred.enet.dec.com (01/26/91)
In article <1991Jan24.221720.25460@ims.alaska.edu>, fnddr@acad3.alaska.edu (Rice Don D) writes... >One possible problem: some libraries in /usr/lib are links to >/usr/lib/cmplrs/cc2.0, while libraries in /usr/lib/cmplrs/f772.1 point into >/usr/lib/cmplrs/cc2.1. Having a mix of 2.0 and 2.1 libraries sounds like >bad news to me. Those are version numbers from different products, so that should not be a problem. >We found that we can get the whole mess to link in single precision by >doing this: > cc -c main.c > f77 -o prog main.o sub.o -lF77 -lI77 -lm >I had some reservations about using f77 with a C main program, but it >seems to work. Yuk. Something is broken here, even if it is only the >Fortran documentation. That is definitely one way to get it to work, though I agree it is messy. The problem is that any FORTRAN compiler provides a whole environment, not just a way to call functions. Compiler developers try to do as much as they can to make the environment "lightweight", but there are still all sorts of potential hidden gotchas. If you want to find out the right set of libraries to use when linking using cc, try the "-v" option on the f77 link command you gave above. It will show which libraries f77 specifies, and you can then duplicate that listof libraries in your cc link. - Brad
anthony@eeyore.caltech.edu (Lawrence Anthony) (01/27/91)
In article <1991Jan24.001055.3069@ims.alaska.edu> fnddr@acad3.alaska.edu writes: >A couple of cc/f77 problems have turned up (Ultrix 4.0/DS5000/Fortran 2.1). The >Second, when trying to combine a main program written in C with a subroutine >written in Fortran, the Fortran built-in functions aren't found: > > cc -o prog main.c fortsub.o -lF77 -lU77 -lI77 -lm > ld: > Undefined: > sinf > cosf > sqrtf try "f77 -o prog main.c fortsub.o -lU77 -lI77 -lF77 -lm -lc". no guarantees, but it works for me. lawrence anthony lza@ulysses.caltech.edu
geyer@aylmer.uchicago.edu (Charles Geyer) (02/24/91)
[I missed the beginning of the thread, I hope these attributions are correct] In article <1991Jan24.001055.3069@ims.alaska.edu Don Rice (fnddr@acad3.alaska.edu) writes: > A couple of cc/f77 problems have turned up (Ultrix 4.0/DS5000/Fortran 2.1).... > ... when trying to combine a main program written in C with a subroutine > written in Fortran, the Fortran built-in functions aren't found: > > cc -o prog main.c fortsub.o -lF77 -lU77 -lI77 -lm > ld: > Undefined: > sinf > cosf > sqrtf In article <1991Jan24.194343.5054@morrow.stanford.edu> farrell@tioga.Stanford.EDU (Phil Farrell) replies: > Is the C compiler even finding the libraries? As installed, Fortran 2.1 > libraries are in /usr/lib/cmplrs/f77, but the C compiler looks for > those -lF77 etc directives in /usr/lib. I created symbolic links > for libF77.a, libI77.a, and libU77.a from /usr/lib/cmplrs/f77 to /usr/lib > on my system to address this problem. > > Secondly, you realize that the linker only searches a library once for > any references on its current "unresolved" list. If a routine from one > library calls one from another library that has already been searched, > that will created an undefined reference. You might play with the > order of libraries on your command line, or even add another -l command > at the end to search the library a second time. My solution to this problem is the following LDFLAGS = -L/usr/lib/cmplrs/f77 LIBS = -lF77 -lI77 -lU77 -lm OBJS = prog.o foo.o baz.o prog : $(OBJS) $(CC) $(LDFLAGS) -o $@ $(OBJS) $(LIBS) My question is this: What is the "offical" right way to do this, if any? Is there something in the DEC manuals about calling Fortran from C? Please don't tell me to rtfm, this is a Sun-only site here. I am trying to solve some problems for a friend and get myself ready for a move to a DEC-only site in September. Charles Geyer Department of Statistics University of Chicago geyer@galton.uchicago.edu