Fortran - Intel Fortran v8 can't link w/ library -- but CVF 6.6 can -- why?

Author

Intel Fortran v8 can't link w/ library -- but CVF 6.6 can -- why?

Rolf S. Arvidson

2004-05-18, 12:31 am

Hi,
Have just started using IVF8, converting projects from CVF, and am having
problems linking to libraries that previously posed no problem under CVF 6.
IVF _finds_ the library ok (I can verify this by removing the declared
dependency and location in the project description).
The source code is extremely simple, I'm just trying to access to the
function J_START:

PROGRAM japi_test
INTERFACE
LOGICAL FUNCTION j_start()
END FUNCTION
END INTERFACE
IF( .NOT. j_start()) THEN
PRINT *, "can't connect to JAPI Kernel"
END IF
END PROGRAM japi_test

This compiles fine, but the linker reports

main.obj : error LNK2019: unresolved external symbol _J_START referenced in
function _MAIN__
Debug/f90_test.exe : fatal error LNK1120: 1 unresolved externals

Here is the result of dumpbin (dumpbin /LINKERMEMBER:1 japi.lib) on the
import file:

Microsoft (R) COFF/PE Dumper Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.

Dump of file japi.lib

File Type: LIBRARY

Archive member name at 8: /
3E5B883A time/date Tue Feb 25 09:14:02 2003
uid
gid
0 mode
22D6 size
correct header end

397 public symbols

4A4C _DllMain@12
4C6C _J_ADD@8

Gerry Thomas

2004-05-18, 1:31 am

"Rolf S. Arvidson" <rsa4046@earthlink.net> wrote in message
news:lifqc.13183$zO3.1807@newsread2.news.atl.earthlink.net...
> Hi,
> Have just started using IVF8, converting projects from CVF, and am having
> problems linking to libraries that previously posed no problem under CVF
6.
> IVF _finds_ the library ok (I can verify this by removing the declared
> dependency and location in the project description).
> The source code is extremely simple, I'm just trying to access to the
> function J_START:
>
> PROGRAM japi_test
> INTERFACE
> LOGICAL FUNCTION j_start()
> END FUNCTION
> END INTERFACE
> IF( .NOT. j_start()) THEN
> PRINT *, "can't connect to JAPI Kernel"
> END IF
> END PROGRAM japi_test
>
> This compiles fine, but the linker reports
>
> main.obj : error LNK2019: unresolved external symbol _J_START referenced
in
> function _MAIN__
> Debug/f90_test.exe : fatal error LNK1120: 1 unresolved externals
>
>
> Here is the result of dumpbin (dumpbin /LINKERMEMBER:1 japi.lib) on the
> import file:
>
> Microsoft (R) COFF/PE Dumper Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> Dump of file japi.lib
>
>
> File Type: LIBRARY
>
> Archive member name at 8: /
> 3E5B883A time/date Tue Feb 25 09:14:02 2003
> uid
> gid
> 0 mode
> 22D6 size
> correct header end
>
> 397 public symbols
>
> 4A4C _DllMain@12
> 4C6C _J_ADD@8
> .
> .
> <snip>
> <snip>
> .
> .
> 1DEE8 _J_SOUND@8
> 1E106 _J_START@0
> 1E324 _J_SYNC@0
> .
> .
> <snip>
> <snip>
> .
> .
> 1EDDC _J_WINDOW@4
> 1EFFC _J_WINDOWLISTENER@8
> 4636 __IMPORT_DESCRIPTOR_japi
> 48BC __NULL_IMPORT_DESCRIPTOR
> 4A4C __imp__DllMain@12
> 4C6C __imp__J_ADD@8
> .
> .
> <snip>
> <snip>
> .
> .
> 1DEE8 __imp__J_SOUND@8
> 1E106 __imp__J_START@0
> 1E324 __imp__J_SYNC@0
> .
> .
> <snip>
> <snip>
> .
> .
> 4978 japi_NULL_THUNK_DATA
>
>
> So I can see the function (J_START) that I'm trying to import, and the
name
> agrees with that in my .OBJ file, as the result of dumpbin on the object
> file seems to indicate:
>
> dumpbin /SYMBOLS debug\MAIN.OBJ
>
>
> Microsoft (R) COFF/PE Dumper Version 7.10.3077
> Copyright (C) Microsoft Corporation. All rights reserved.
>
>
> Dump of file debug\MAIN.OBJ
>
> File Type: COFF OBJECT
>
> COFF SYMBOL TABLE
> 000 00000000 DEBUG notype Filename | .file
> C:\home\rolf\Visual Studio Projects\f90_test\main.f90
> 004 00000000 SECT1 notype Static | .text
> Section length 78, #relocs 6, #linenums 4, checksum 0
> 006 00000000 SECT2 notype Static | .data
> Section length 0, #relocs 0, #linenums 0, checksum 0
> 008 00000000 SECT3 notype Static | .bss
> Section length 0, #relocs 0, #linenums 0, checksum 0
> 00A 00000000 SECT4 notype Static | .rdata
> Section length 0, #relocs 0, #linenums 0, checksum 0
> 00C 00000000 SECT5 notype Static | .tls$
> Section length 0, #relocs 0, #linenums 0, checksum 0
> 00E 00000000 SECT6 notype Static | .data1
> Section length 2C, #relocs 0, #linenums 0, checksum 0
> 010 00000000 SECT7 notype Static | .text1
> Section length 0, #relocs 0, #linenums 0, checksum 0
> 012 00000000 SECT1 notype () External | _MAIN__
> tag index 00000014 size 00000078 lines 00000459 next function
00000000
> 014 00000000 SECT1 notype BeginFunction | .bf
> line# 0001 end 00000000
> 016 00000004 SECT1 notype .bf or.ef | .lf
> 017 00000078 SECT1 notype EndFunction | .ef
> line# 000a
> 019 00000000 UNDEF notype () External | _for_set_reentrancy
> 01A 00000000 UNDEF notype () External | _J_START
> 01B 00000000 UNDEF notype () External | _for_write_seq_lis
> 01C 00000000 SECT6 notype Static | STRLITPACK_1
> 01D 00000008 SECT6 notype Static | STRLITPACK_0
> 01E 00000028 SECT6 notype Static | LITPACK_0
> 01F 00000000 SECT8 notype Static | .debug$S
> Section length 76, #relocs 2, #linenums 0, checksum 0
> 021 00000000 SECTB notype Static | .debug$T
> Section length 1C, #relocs 0, #linenums 0, checksum 0
> 023 00000000 SECT9 notype Static | .drectve
> Section length 8B, #relocs 0, #linenums 0, checksum 0
> 025 00000000 SECTA notype Static | .trace
> Section length 68, #relocs 2, #linenums 0, checksum 0
>
> String Table Size = 0x4F bytes
>
> Summary
>
> 0 .bss
> 0 .data
> 2C .data1
> 76 .debug$S
> 1C .debug$T
> 8B .drectve
> 0 .rdata
> 78 .text
> 0 .text1
> 0 .tls$
> 68 .trace
>
> This same source code, together with the identical .LIB import file,
> compiles/links just fine in CVF. Anybody have any idea what I'm doing
wrong?
> Any help would be greatly appreciated --
>
> Cheers, Rolf
>
>

Take your problem to http://softwareforums.intel.com/ids/board?board.id=5
or Intel Premier Support unless you're a freeloader in which case join the
United Way lineup and compete with the defeated.

--
E&OE

Ciao,
Gerry T.
______
"The enemy is anybody who's going to get you killed, no matter which side
he's on." -- Yossarian, in Catch 22.

Tim Prince

2004-05-18, 2:31 am

Catherine Rees Lay

2004-05-18, 5:31 am

In article <lifqc.13183$zO3.1807@newsread2.news.atl.earthlink.net>, Rolf
S. Arvidson <rsa4046@earthlink.net> writes
>Hi,
>Have just started using IVF8, converting projects from CVF, and am having
>problems linking to libraries that previously posed no problem under CVF 6.
>IVF _finds_ the library ok (I can verify this by removing the declared
>dependency and location in the project description).
>The source code is extremely simple, I'm just trying to access to the
>function J_START:
>
> PROGRAM japi_test
> INTERFACE
> LOGICAL FUNCTION j_start()
> END FUNCTION
> END INTERFACE
> IF( .NOT. j_start()) THEN
> PRINT *, "can't connect to JAPI Kernel"
> END IF
> END PROGRAM japi_test
>
>This compiles fine, but the linker reports
>
>main.obj : error LNK2019: unresolved external symbol _J_START referenced in
>function _MAIN__
>Debug/f90_test.exe : fatal error LNK1120: 1 unresolved externals
>
Your external symbol as exported is _J_START@0, not _J_START. This is
what CVF would have been looking for by default which is why you were OK
with CVF. I'm not sure why Intel isn't looking for the same, but you
should be able to tell it to do so - perhaps try Mixed Language
Programming in the help system (this is where it is for CVF).

And don't worry about posting here. I for one find this sort of question
appropriate and useful, even though I'm not currently using the Intel
compiler.

Catherine. (I work for Polyhedron as a programmer).
--
Catherine Rees Lay
To email me, use my first name in front of the "at".

Jugoslav Dujic

2004-05-18, 6:31 am

Catherine Rees Lay wrote:
| In article <lifqc.13183$zO3.1807@newsread2.news.atl.earthlink.net>, Rolf
| S. Arvidson <rsa4046@earthlink.net> writes
|| Hi,
|| Have just started using IVF8, converting projects from CVF, and am having
|| problems linking to libraries that previously posed no problem under CVF 6.
|| IVF _finds_ the library ok (I can verify this by removing the declared
|| dependency and location in the project description).
|| The source code is extremely simple, I'm just trying to access to the
|| function J_START:
||
|| This compiles fine, but the linker reports
||
|| main.obj : error LNK2019: unresolved external symbol _J_START referenced in
|| function _MAIN__
|| Debug/f90_test.exe : fatal error LNK1120: 1 unresolved externals
||
| Your external symbol as exported is _J_START@0, not _J_START. This is
| what CVF would have been looking for by default which is why you were OK
| with CVF. I'm not sure why Intel isn't looking for the same,

....because default calling convention changed in the meantime from
stdcall/len_after_string_arg to cdecl/len_at_the_arglist_end.

| but you
| should be able to tell it to do so - perhaps try Mixed Language
| Programming in the help system (this is where it is for CVF).

If the original project is written in CVF, the simplest way is to
right-click the project name in "Solution explorer" and select
"Extract Compaq Visual Fortran Items". This will give you IVF
project "compatible" with CVF default settings.

Another solution, with same effect, is to change "Calling convention"
somewhere in Project Properties/Fortran/External Procedure from
"Default" to "CVF".

The third solution is to spell out the calling convention in INTERFACE
blocks for library procedures via !DEC$ATTRIBUTES STDCALL etc.

Note that Intel does not guarantee binary compatibility of libraries
of CVF on IVF. They tend to work, except when they don't. A potential
source of problems is that underlying run-time libraries are not
mutually compatible, so you basically have to apply the same precautions
as if it were a "mixed-language" program.

--
Jugoslav
___________
www.geocities.com/jdujic

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Rolf S. Arvidson

2004-05-18, 10:45 am

"Jugoslav Dujic" <jdujic@yahoo.com> wrote in message
news:2gu3dfF6veggU1@uni-berlin.de...
> Catherine Rees Lay wrote:
> | Your external symbol as exported is _J_START@0, not _J_START. This is
> | what CVF would have been looking for by default which is why you were OK
> | with CVF. I'm not sure why Intel isn't looking for the same,
>
> ...because default calling convention changed in the meantime from
> stdcall/len_after_string_arg to cdecl/len_at_the_arglist_end.

Catherine and Jugoslav,
Thanks for picking up on this, I had ignored it --

> Another solution, with same effect, is to change "Calling convention"
> somewhere in Project Properties/Fortran/External Procedure from
> "Default" to "CVF".

Setting Project Description | Configuration Properties | Fortran | External
Procedures | Calling Convention = CVF
fixed it. Thanks all.
Cheers, Rolf

Sponsored Links