Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28457 Discussions

Linking .lib file with visual studio

Yuming_F_
Beginner
938 Views

I have a MAIN file that calls a couple of functions in a apples.lib file. I drag the oranges.f and apples.lib file into the solution explorer, under the "Source Files". After pressing "Build Solution", 3 errors come up : "Fatal error LNK1120: 2 unresolved externals", "error LNK2019 : unresolved external symbol ABC referenced in function _MAIN__", "error LNK2019: unresolved external symbol XYZ in function _MAIN__".

I am able however to successfully compile and link the files with a makefile and using "nmake /f makefile". What am I missing to do it in Visual Studio ? I have Parallel Studio XE 2013 with VS2010.

Thank you.

0 Kudos
8 Replies
Steven_L_Intel1
Employee
938 Views

You seem to have done things correctly. The first thing I would do is look at the buildlog.htm file and look at the link command to see if your .lib was included. If not, then perhaps the .lib was not added correctly.

0 Kudos
Yuming_F_
Beginner
938 Views

I opened the build log files. This is the Link command I think you are speaking of :

Link /OUT:"Debug\Console2.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"c:\users\**********\documents\visual studio 2010\Projects\Console2\Console2\Debug\Console2.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"c:\users\**********\documents\visual studio 2010\Projects\Console2\Console2\Debug\Console2.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"c:\users\**********\documents\visual studio 2010\Projects\Console2\Console2\Debug\Console2.lib" "Debug\oranges.obj" "C:\Users\**********\Documents\Visual Studio 2010\Projects\Console2\Console2\apples.lib"

 

It looks like my .lib does appear properly included at the end of the line. 

Thank you. 

0 Kudos
Steven_L_Intel1
Employee
938 Views

Ok. Then you'll need to figure out if that .lib has the symbol you're looking for. Maybe your makefile is using a different library?

If you open a compiler command prompt, you can use "dumpbin -symbols yourlib.lib > lib.txt" to put in lib.txt a report of all the symbols defined (and referenced) in the .lib. Search it to see if the one the linker complained about is there. Pay very close attention to whether or not there is an underscore prefix or an @n suffix.

What compile options are used in the makefile vs. Visual Studio? Maybe there's a difference there that accounts for the problem. For example, if you had /iface:cvf in one but not the other, that would be an issue.

0 Kudos
Yuming_F_
Beginner
938 Views

I dumped the apples.lib file, and I did find the two symbols that the Visual Studio did not find, they did not have any prefix or @n suffix. The name did however end with .f 

In my makefile, there is only /nologo /warn:nofileopt options to make the .obj file, and the link command does not have any options at all.

What is the manifest options, and should the /IMPLIB console2.lib be present? 

0 Kudos
Steven_L_Intel1
Employee
938 Views

Ignore the manifest and /implib - not relevant. You've masked out all the symbol spellings so I'm missing some clues that might help you. Can you show one of the error messages with the symbol name intact and then the line from the symbol dump that names the symbol? I don't know what a name ending in .f might signify. Please also show the compile options used in both the makefile and the project. (For the project, go to Fortran > Command Line and you can see them all shown there.)

0 Kudos
Yuming_F_
Beginner
938 Views

Intel Fortran compiler options : /nologo /debug:full /Od /warn:interfaces /module:"Debug\\" /object:"Debug\\" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c

makefile compiler options : /c /nologo /warn:nofileopt /

"error LNK2019: unresolved external symbol _ABC referenced in function _MAIN__" in file oranges.obj

dumpbin:

COFF SYMBOL TABLE

000 00000000 DEBUG  notype       Filename     | .file
    ABC.f
002 00000000 SECT1  notype       Static       | .text
    Section length  910, #relocs  156, #linenums    0, checksum        0
004 00000000 SECT1  notype ()    External     | ABC

0 Kudos
mecej4
Honored Contributor III
938 Views

Yunming F.: you have not provided sufficient information about your programs to enable the problem to be diagnosed.

From what you have written, it appears that source file oranges.f does one of the following:

  • contains an EXTERNAL :: ABC, XYZ statement,
  • calls subroutines ABC and XYZ
  • references functions ABC and XYZ in expressions

However, the dumpbin output of oranges.obj that you gave does not show any references to XYZ. So far you have not given any evidence (such as a dumpbin output) that either of these symbols (ABC and XYZ), is to be found in apples.lib.

0 Kudos
Steven_L_Intel1
Employee
938 Views

Actually, Yunming did provide enough information this time. Remember what I said about paying  "very close attention" to underscores and @n in the symbol name?

Look at the error message and you see that the linker is looking for "_ABC", with a leading underscore. Now look in the symbol dump and you'll see "ABC" with no underscore. (The .f you mentioned earlier is the source file name, recorded in the object.)

Why the mismatch?  Your Visual Studio project is being built as a "Win32" configuration, or 32-bit, but the library was built for 64-bit (x64). The way I can tell is that the decoration convention is different between 32-bit and 64-bit. 32-bit prepends a leading underscore to global symbol names by default, 64-bit does not.

Now, why did it work in your makefile? You probably configured the command prompt session for a 64-bit build ("Intel 64").

The solution is to select Build > Configuration Manager... Under Solution Platform select New... and make sure that x64 is selected as the platform name. Click OK, close the manager and you'll now be set into an x64 configuration. Most likely, when you build this, it will link.

The moral of this story, as it often is here, is that you'll get a solution fastest if you don't withhold information. This is especially the case for error messages  - we need to see the full and exact text of the error message, not just a message number or with symbol names removed. Also we need to see actual code, ideally a complete example that shows the problem, and not snippets, pseudocode or "code like this".

0 Kudos
Reply