trying to run f77 source code but getting "unresolved external errors"

tchill · ‎07-23-2004

Hi, I am fairly new to fortran and would appreciate any help.

The situation is this, I am trying to run f77 code using cvf 6.6. The code appears to link fine, but on building it fails. Errors are fro example:

capsori.obj : error LNK2001: unresolved external symbol _CHACHA@40

Where CHACHA is a subroutine contained within the same source file. The errors appear to be for all the subroutines used, (well the first 8 called before a fatal error LNK1120 stops the building).

The strange thing is that the code complies on a Sun f77 complierwithout any problem. This is not ideal for me as I don't have regular access to Sun machines, need it running on cvf, any ideas?

I have been creating the program as a fortran console application. Are there any libraries I am likely to be missing?

Cheers for any help, T

ArturGuzik · ‎07-23-2004

Do you callChacha subroutinewith the same number and type of arguments?

A.

Message Edited by ArturGuzik on 07-23-2004 06:45 AM

tchill · ‎07-23-2004

Yes, same number and type of arguments. Definately runs on the Sun f77 compiler without alteration.

cheers, T

Jugoslav_Dujic · ‎07-23-2004

Yes, same number and type of arguments.

Please pardon my stubbornness, but are you really sure?

Definately runs on the Sun f77 compiler without alteration.

This still does not prove much. CVF is simply more picky regarding prototype matching -- most likely candidates are CHARACTER/BYTE mismatches.

You can still

- go to command prompt and browse to your Debug or Release directory

- type

dumpbin /symbols capsori.obj > temp.txt

- open temp.txt in a text editor and search for CHACHA (you will find it several times), but I'll bet that it will be e.g. _CHACHA@36 or _CHACHA@44 somewhere.

(The "magic number" behind @ is 4*total_number_of_arguments+ 4*number_of_character_arguments).

As a last resort, you can compile with Project/Settings/Fortran/External Procedures/Argument convention->C, by reference (/iface:cref), and String Length Argument Passing->After all args (/iface:nomixed_str_len_arg), but I'd recommend that you fix problems in code if you identify them.

Jugoslav

ArturGuzik · ‎07-23-2004

Jugoslav is (as always) absolutely right. The fact thatthe code compiles (does it mean runs?) with no problem on Sun does not mean much. Isaw thismany times while porting codes from other platforms/older compiler versions. If you, additionally,add include files/explicit interfaces...well, you can (sometimes) seethemirracles.

A.

tchill · ‎07-23-2004

HI,

Sorry the model does run on the Sun workstation, (with the exception of some IEEEfloting point exception flags,which I was expecting).

So, after following the directions from Jugoslav,I looked at the temp.txt that was created, have copied it to the bottom of this post. Only found one instance of chacha and it was CHACHA@40. It does make sense that the problem may lie with character/byte mismatches, but just out of interest how can the program then run on the Sun with such major errors?

Also tried the 'last resort' ideas but I still didn't manage to get the program to run. I actually don't mind if the program is only bodged into running, as I will be writingit in f90/95.

(once again) Cheers, T

Dump of file capsori.obj

File Type: COFF OBJECT

COFF SYMBOL TABLE
000 00000000 DEBUG notype Filename | .file
C:Documents and SettingsTimDesktopPBLPBLv2capsori.f
005 00000000 SECT1 notype Static | .text
Section length 7D3B, #relocs 9C8, #linenums 1BB, checksum 0
007 00000000 SECT2 notype Static | .rdata
Section length 3EA, #relocs 0, #linenums 0, checksum 0
009 00000000 SECT3 notype Static | .data
Section length 2638, #relocs 0, #linenums 0, checksum 0
00B 00000000 SECT4 notype Static | .debug$S
Section length 123C, #relocs 1AA, #linenums 0, checksum 0
00D 00000000 SECT5 notype Static | .debug$T
Section length 50, #relocs 0, #linenums 0, checksum 0
00F 00000000 SECT6 notype Static | .bss
Section length 16E0, #relocs 0, #linenums 0, checksum 0
011 00000000 SECT7 notype Static | .drectve
Section length 74, #relocs 0, #linenums 0, checksum 0
013 00000000 SECT8 notype Static | .trace
Section length 51B, #relocs 3, #linenums 0, checksum 0
015 00000000 SECT1 notype () External | _PBLDRV@0
tag index 00000017 size 00007BB6 lines 0000C0CC next function 0000001C
017 00000000 SECT1 notype BeginFunction | .bf
line# 017c end 0000001E
019 000001B5 SECT1 notype .bf or.ef | .lf
01A 00007BB6 SECT1 notype EndFunction | .ef
line# 0546
01C 00007BB6 SECT1 notype () External | _ERR1@8
tag index 0000001E size 00000185 lines 0000CB0A next function 00000000
01E 00007BB6 SECT1 notype BeginFunction | .bf
line# 05f3 end 00000000
020 00000006 SECT1 notype .bf or.ef | .lf
021 00007D3B SECT1 notype EndFunction | .ef
line# 05fa
023 0000000 0 UNDEF notype () External | _for_check_flawed_pentium@0
024 00000000 UNDEF notype () External | _for_set_reentrancy@4
025 00000678 UNDEF notype External | _AUXIL
026 00000000 UNDEF notype () External | _for_write_seq_lis
027 00000000 UNDEF notype () External | _for_write_seq_fmt
028 00000000 UNDEF notype () External | _for_read_seq_fmt
029 00000000 UNDEF notype () External | __OtsStringCompareEqlPadded
02A 00000000 UNDEF notype () External | __OtsMoveMinimum
02B 00000000 UNDEF notype () External | __OtsFill
02C 00000000 UNDEF notype () External | _for_write_seq_lis_xmit
02D 00000000 UNDEF notype () External | _for_open
02E 00000000 UNDEF notype () External | _for_read_seq_lis
02F 00000000 UNDEF notype () External | _for_read_seq_lis_xmit
030 00000000 UNDEF notype () External | _for_write_seq
031 00000000 UNDEF notype () External | _for_write_seq_xmit
032 00000000 UNDEF notype () External | _for_write_seq_fmt_xmit
033 00000008 UNDEF notype External | _HCALC
034 00000FA0 UNDEF notype External | _FIELDS
035 00000000 UNDEF notype () External | _for_close
036 00000000 UNDEF notype () External | __FIsin
037 00000000 UNDEF notype () External | _CHACHA@40
038 00000000 UNDEF notype () External | _ZTOSIG@20
039 00000000 UNDEF notype () External | _HFAK@8
03A 00000000 UNDEF notype () External | __FIIfexp_
03B 00000000 UNDEF notype () External | _SIGTOZ@16
03C 00000000 UNDEF notype () External | _SUN@0
03D 00000000 UNDEF notype () External | _SFLX@40
03E 00000000 UNDEF notype () External | _PBLL@20
03F 00000000 UNDEF notype () External | _PRINT@0
040 00000000 UNDEF notype () External | _for_stop_core
041 00000000 UNDEF notype () External | _for_stop_core
042 00000000 UNDEF notype () External | _for_stop_core
043 00000000 UNDEF notype () External | _for_stop_core
044 00000000 UNDEF notype () External | _for_stop_core
045 00000000 SECT1 notype () External | _MAIN__
046 00001260 SECT3 notype External | _GRID
047 0000032C UNDEF notype External | _GRID
048 00001590 SECT3 notype External | _SOIL
049 00000060 UNDEF notype External | _SOIL
04A 000015F0 SECT3 notype External | _SOIL1
04B 0000002C UNDEF notype External | _SOIL1
04C 00001620 SECT3 notype External | _SOIL2
04D 00000030 UNDEF notype External | _SOIL2
04E 00001650 SECT3 notype External | _PBL
04F 00000E3C UNDEF notype External | _PBL
050 00002490 SECT3 notype External | _SFCL
051 0000004C UNDEF notype External | _SFCL
052 000024E0 SECT3 notype External | _RAD
053 00000030 UNDEF notype External | _RAD
054 00002510 SECT3 notype External | _SOIL3
055 000000B0 UNDEF notype External | _SOIL3
056 000025C0 SECT3 notype External | _AUXI2
057 0000000C UNDEF notype External | _AUXI2
058 000025D0 SECT3 notype External | _XLUN
059 0000000C UNDEF notype External | _XLUN
05A 000025E0 SECT3 notype External | _SNOW
05B 0000000C UNDEF notype External | _SNOW
05C 000025F0 SECT3 notype External | _SOIL4
05D 00000008 UNDEF notype External | _SOIL4
05E 00002600 SECT3 notype External | _WFK74
05F 00000038 UNDEF notype External | _WFK74
060 00000000 SECT1 notype () External | _PBLDRV
061 00007BB6 SECT1 notype () External | _ERR1
062 00000000 ABS notype External | _A1
063 00000000 ABS notype External | _A2
064 00000000 ABS notype External | _A3
065 00000000 ABS notype External | _A4

String Table Size = 0x1B7 bytes

Summary

16E0 .bss
2638 .data
123C .debug$S
50 .debug$T
74 .drectve
3EA .rdata
7D3B .text
51B .trace

Steven_L_Intel1 · ‎07-23-2004

CVF (like Microsoft Fortran PowerStation before it) defaults to the STDCALL calling mechanism, which is unique to Windows on IA-32. It requires that the caller and callee agree on the number of bytes pushed on the stack during a routine call because it is the called routine that pops the stack. This is a bit faster than the other available mechanism known as "C". Note that all the Win32 APIs use STDCALL and so do interpretive languages such as VB.

To help prevent stack corruption, the convention for STDCALL has the name of the routine suffixed with @n, where n is the number of bytes pushed on the stack. That way, the linker will complain if there is a mismatch.

Sun, and other UNIX Fortrans (as well as most other Fortrans on IA-32) use a calling mechanism that doesn't require that the called routine to pop the stack, so there is typically not a convention of annotating Fortran routine names and mismatches can go undetected.

I will note that Intel Visual Fortran uses the "C" mechanism by default, but STDCALL is available as an option.

ArturGuzik · ‎07-24-2004

Making (this particular and any others) routines interface explicit will tell you more about what CVF doesn't like in your code.

A few weeks ago I was porting MacOSX (Unix-based) Fortran code. Code was running perfectly on it. CVF detected couple of mismatches at building and explicit interfaces revealed another two.

A.

ArturGuzik · ‎07-24-2004

... and one more thing. You dumpbin-ed capsori.obj and found out that chacha@40 is called. You haven't checked and compared withother *.obj files (which use chacha routine). Have you?

A.

tchill · ‎07-24-2004

Sorry if I am being slow, but how do you make the routine interfaces explicit?

(I think that capsouri.obj is the only to call CHACHA@40)

What am I to take from the temp.txt file above, I don't really understand what it is telling me)

confused, (but still grateful), T

ArturGuzik · ‎07-25-2004

The interface block must, naturally, match the subroutine declaration. Then you can insert USE Chacha_Face in the source of the routine which calls Chacha. The other option is to type it in the routine itself (CVF Help, again):

Code:

The following shows another example:

!An interface to an external subroutine SUB1 with header:
!SUBROUTINE SUB1(I1,I2,R1,R2)
!INTEGER I1,I2
!REAL R1,R2

INTERFACE
  SUBROUTINE SUB1(int1,int2,real1,real2)
    INTEGER int1,int2
    REAL real1,real2
  END SUBROUTINE SUB1
END INTERFACE

INTEGER int
. . .

Hope that will help (tofind the mismatch). The dumpbin story was tocheck whether you call Chacha with different number/type arguments (you can try to compile the Chacha source to a separate .obj file, dumpbin it, and see whether it also gives youChacha@40)

A.

ArturGuzik · ‎07-25-2004

I don't know why butthe first part of my message was lost while submiting it (pagination?). Below I will try to reproduce it in a shorter version, so this is part 1, the the previous post actually part 2.

A.

--------------------------------------------------------------------------------------------------------

Well, so the problem is very 'isolated' if you call the famous Chacha only in one place. Explicit interface (based on example from CVF Help, take a look at Programmer's Guidefor much, much better explanation than this):

Code:

MODULE CHACHA_FACE
  INTERFACE
    SUBROUTINE CHACHA (D)
      REAL, INTENT(IN) :: D(:)
    END SUBROUTINE CHACHA
  END INTERFACE
END MODULE CHACHA_FACE

A.

tchill · ‎07-26-2004

Cheers for all your help, going totake sometime to try the suggestions. But your help has been appreciated. Wish me luck...