Trouble with cc/f77

[Rice Don D]

In article <1991Jan24.203050.6702 at morrow.stanford.edu>, caroline at pangea.Stanford.EDU (Caroline Lambert) writes...
>In article <1991Jan24.194343.5054 at morrow.stanford.edu> farrell at tioga.Stanford.EDU (Phil Farrell) writes:
>>In article <1991Jan24.001055.3069 at ims.alaska.edu>
>>Don Rice (fnddr at 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 at flux.gi.alaska.edu
Geophysical Institute                     E-mail:   fnddr at alaska.bitnet
University of Alaska                      Phone:    (907) 474-7569
Fairbanks, AK 99775                       Loran:    64.86N 212.16E