Unresolved external symbol against abstract interface

[Ben3]

Hi,

I'm getting an unresolved external symbol from an abstract interface in a static library.

In a module I have the following abstract type and interface, which is compiled into a static library with many other modules.

[fortran]type, abstract, public :: FermActType
 contains
   procedure(txt_io), deferred :: Get
   procedure(txt_io), deferred :: Put
   procedure :: Read => ReadFermActType
   procedure :: Write => WriteFermActType
end type FermActType

abstract interface
   subroutine txt_io(this,file_unit)
     import :: FermActType
     class(FermActType) :: this
     integer :: file_unit
   end subroutine txt_io
end interface[/fortran]

I then have my main program which links against the library (against procedures that use the abstract type and its children), but when I attempt to link I get this:

[plain]Linking...
cola.lib(fermacttypes.obj) : error LNK2001: unresolved external symbol TXT_IO
x64\\Debug\\dibaryon.exe : fatal error LNK1120: 1 unresolved externals[/plain]

I found this thread (http://software.intel.com/en-us/forums/showthread.php?t=85691) for the Linux compiler, which seems perhaps similar?

My version of ifort is

[plain]Intel Visual Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.1.0.233 Build 20110811
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.[/plain]

I realise this isn't a compilable example, but I don't know how to get the Windows compiler/linker to give me info about which procedure in the library the unresolved is coming from.

Any ideas?

Cheers,
Ben

[mecej4]

The full context is there for the taking:

cola.lib(fermacttypes.obj):errorLNK2001:unresolvedexternalsymbolTXT_IO

Look for an external symbol (subprogram or common block name) called TXT_IO in the object fermacttypes.obj in the library cola.lib.

[Ben3]

Thanks mecej4,

Sorry, I probably should have said in my original post - I used dumpbin to check the object file, and the external symbol TXT_IO is indeed there. The problem is that the only references to TXT_IO in the source for that object file is what I posted before - the abstract interface. Since it isn't acutally a procedure, why is there a corresponding symbol in the object file?

The question about getting the linker to produce more info was regarding why it linked previously, which I figured out afterwards was because previously it wasn't linking against that object in the library (but rather, other contained objects) until I added a call to one of its routines.

Thanks,
Ben

[Steven_L_Intel1]

We know of two compiler bugs that can produce this symptom. One of them, DPD200169377, is fixed in Update 6. The other, which you have probably encountered, is DPD200173134 and is not yet fixed - that's the one you linked to.

If you can provide a compilable example we can be sure that we fix yours.

[Ben3]

I've narrowed it down to using a typebound function from a type which extends another type which extends the base abstract type. The attached files are compilable and exhibit the error.

[plain]>> ifort /o module.obj /c module.f90
>> ifort /o program.exe program.f90 module.obj
Intel Visual Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.1.0.233 Build 20110811
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

Microsoft  Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:program.exe
-subsystem:console
program.obj
module.obj
module.obj : error LNK2001: unresolved external symbol TXT_IO
program.exe : fatal error LNK1120: 1 unresolved externals[/plain]

Also, running dumpbin on the object file from the module gives this:

[plain]Microsoft  COFF/PE Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file module.obj

File Type: COFF OBJECT

COFF SYMBOL TABLE
000 00000000 DEBUG  notype       Filename     | .file
    module.f90
002 00000000 SECT1  notype       Static       | .text
    Section length   F0, #relocs    D, #linenums    0, checksum        0
004 00000000 SECT1  notype ()    External     | TESTMODULE.
005 00000010 SECT1  notype ()    External     | TESTMODULE_mp_READFERMACTTYPE
006 00000030 SECT1  notype ()    External     | TESTMODULE_mp_GET_WILSON
007 00000040 SECT1  notype ()    External     | TESTMODULE_mp_PUT_WILSON
008 00000050 SECT1  notype ()    External     | TESTMODULE_mp_GET_CLOVER
009 00000060 SECT1  notype ()    External     | TESTMODULE_mp_PUT_CLOVER
00A 00000070 SECT1  notype ()    External     | TESTMODULE_mp_PRINT_CLOVER
00B 000000E0 SECT1  notype ()    External     | TESTMODULE_mp_PRINT_WILSON
00C 00000000 SECT2  notype       Static       | .xdata
    Section length    8, #relocs    0, #linenums    0, checksum        0
00E 00000000 SECT3  notype       Static       | .pdata
    Section length    C, #relocs    3, #linenums    0, checksum        0
010 00000000 SECT4  notype       Static       | .rdata
    Section length   40, #relocs    4, #linenums    0, checksum        0
012 00000000 SECT5  notype       Static       | .bss
    Section length   80, #relocs    0, #linenums    0, checksum        0
014 00000000 SECT5  notype       Static       | .T136_
015 00000000 SECT4  notype       Static       | DYNTYPE_PACK_1.0.8
016 00000010 SECT4  notype       Static       | TBPLIST_PACK_1.0.8
017 00000000 UNDEF  notype       External     | TXT_IO
018 00000028 SECT4  notype       Static       | __STRLITPACK_1.0.8
019 00000008 UNDEF  notype       External     | TESTMODULE_mp_I_AM_ROOT
01A 00000000 UNDEF  notype ()    External     | __ImageBase
01B 00000000 SECT6  notype       Static       | .drectve
    Section length   B9, #relocs    0, #linenums    0, checksum        0

String Table Size = 0x125 bytes

  Summary

          80 .bss
          B9 .drectve
           C .pdata
          40 .rdata
          F0 .text
           8 .xdata
[/plain]

The external symbol for the abstract interface is there.

Cheers,
Ben

[Ben3]

I've experimented with different versions of the compiler on Linux. I can reproduce the error with the 12.1.0 20110811 version, but not the 12.0.4 20110427 build. As such, I don't think it's the same issue as the one I linked to (DPD200173134), since that was reported for 12.0.3. Perhaps the issue started at the same time in the Windows version as well.

Interestingly, the object files produced by the two versions of ifort are different. For version 12.0.4 20110427, I get this:

[plain]bjm566@vayu3 ~/Code/testing>nm module.o
0000000000000000 T testmodule._
0000000000000040 T testmodule_mp_get_clover_
0000000000000020 T testmodule_mp_get_wilson_
0000000000000004 C testmodule_mp_i_am_root_
0000000000000060 T testmodule_mp_print_clover_
0000000000000070 T testmodule_mp_print_wilson_
0000000000000050 T testmodule_mp_put_clover_
0000000000000030 T testmodule_mp_put_wilson_
0000000000000010 T testmodule_mp_readfermacttype_[/plain]

while for 12.1.0 20110811, this:

[plain]bmenadue@weyl ~/bmenadue/Code/testing>nm module.o
0000000000000000 r DYNTYPE_PACK_1.0.8
0000000000000010 r TBPLIST_PACK_1.0.8
0000000000000000 r __STRLITPACK_1.0.8
0000000000000000 T testmodule._
0000000000000040 T testmodule_mp_get_clover_
0000000000000020 T testmodule_mp_get_wilson_
0000000000000004 C testmodule_mp_i_am_root_
0000000000000060 T testmodule_mp_print_clover_
00000000000000c0 T testmodule_mp_print_wilson_
0000000000000050 T testmodule_mp_put_clover_
0000000000000030 T testmodule_mp_put_wilson_
0000000000000010 T testmodule_mp_readfermacttype_
                 U txt_io_
0000000000000000 b var$136[/plain]

Cheers,
Ben

[Steven_L_Intel1]

Thanks - we are working on the fix for this now.

[Steven_L_Intel1]

This has been fixed for a release later this year.