- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dumb problem/question: Using Visual Studio 2008 and Intel VF 11.1, I'm trying to link 2 external static fortran libraries to my fortran program, unsuccessfully at this point.
I'm specifying the libraries path under Properties -> Linker -> General -> Additional Library Directories -> F:\folder\subfolder
I've tried to specify the libraries in that folder under Properties -> Linker -> Input -> Additional Dependencies -> name1.lib, name2.lib
What should I be doing? Thanks for any suggestions!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If they are bespoke libaries you might want to consider just adding them to the project , Menu "project", "add existing item" then there is no ambiguity.
If you look under project, properies, linker, command line you should see the libraries are included in the link command.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What error messages did the linker give you? Did it not find the specified libraries, or did it flag unsatisfied externals?
"trying to link unsuccessfully" is not of much help, if we do not know what you tried. The title of the thread is a bit misleading, since you are using VS2008 to link, rather than linking VS2008 itself.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mecej4 wrote:
What error messages did the linker give you? Did it not find the specified libraries, or did it flag unsatisfied externals?
The subrountines that are part of the needed library, each products a typical message such as "... error LNK2019: unresolved external symbol FMSINI referenced in function MAIN__"
Output from the build is as follows:
Compiling with Intel(R) Visual Fortran 11.1.051 [Intel(R) 64]... ifort /nologo /module:"x64\Release\\" /object:"x64\Release\\" /libs:static /threads /c /extfor:f /Qvc9 /Qlocation,link,"D:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64" "F:\FMS1\Source Files\mode2_code.f"
Linking... Link /OUT:"x64\Release\FMS1.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"F:\FMS1\FMS1\Macro3d_Intel\x64\Release\FMS1.exe.intermediate.manifest" /SUBSYSTEM:CONSOLE /IMPLIB:"F:\Macro3d\FMS\fmsnogpu.lib F:\Macro3d\FMS\fmsnoshr.lib" "x64\Release\mode2_code.obj" "F:\Macro3d\FMS\Include Files\fmsnogpu.lib" "F:\Macro3d\FMS\Include Files\fmsnoshr.lib"
Link: executing 'link'
mode2_code.obj : error LNK2019: unresolved external symbol FMSINI referenced in function MAIN__
etc.
The 2 libraries I'm trying to link are fmsnogpu.lib and fmsnoshr.lib.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you expect the FMSINI reference to be satisfied in those libraries? You might run dumpbin /symbols on the libraries to see what symbols are there, if they are recognizable in Visual Studio format, and whether they are "mangled" in some way, such as appended underscore.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The linker line shows clearly that the two libraries are being looked up, but the symbol FMSINI is not defined in either of them. Which of the two libraries is supposed to contain this routine? Have you checked whether the libraries do contain the symbol and could name mangling be the source of the problem?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is it possible your libraries were built for 32-bits? If so, the external names would be different (a leading underscore on 32-bit. none on 64-bit.) You can't mix these.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
Don't think so. All the compiler options for the program using the library are 64-bit. I'm checking with the supplier about the issue since I think I'm doing things right.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The options for the program aren't what is important here - it's how the libraries themselves were built.
Please open a Fortran command prompt window. Set default (cd) to the folder containing the libraries. Type the command:
dumpbin -symbols name1.lib > name1.txt
Now open name1.txt in notepad (obviously you substitute the real library name here) and search for FMSINI. Please show the full line from the file that contains that text.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
From the fmsnoshr.lib, under a heading "COFF SYMBOL TABLE" the first line is
004 00000000 SECT2 notype () External | fmsini
Down a little further is
01D 00000000 UNDEF notype () External | fms$_fmsini
Nothing in fmsnogpu.lib
From this it appears the needed external subrountines are not there?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The routine is there, but in lowercase. This is evidently a C routine. On Windows, Fortran upcases routine names by default - hence the mismatch.
How are these routines declared in your Fortran code? Interface block, EXTERNAL or nothing at all? How many of these routines are you using? There are various ways to solve this but I need to know what your code looks like to recommend the best approach.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Useful info Steve.
Supplier has just said that I need to add two additional files, one .f90 and one .h they provided to reference the C rountines. I'm not experienced enough to figure these things out without a little guidence from them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You evidently modified it by removing the MODULE and END MODULE lines. (The error message suggests you removed one and not the other.)
1. Put the MODULE and END MODULE lines back.
2. Add this .f90 source file to your project or compile it separately.
3. Add USE MODULENAME (where MODULENAME is the name of the module) to each program unit in your program that needs to call one of these routines. This line should go directly after the PROGRAM, SUBROUTINE or FUNCTION statement.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have seen only pieces of your source files, but here is one part that raised a red flag:
!DEC$ATTRIBUTES C, REFERENCE, ALIAS:' fmsini'::FMSINI
Note the leading blank in the alias name. These leading blanks are present in a number of aliases in file fmshdrf.f90; in particular, for FMSINI. Naturally, that is going to cause problems at link time. Try removing the leading blanks and building, or ask your library provider to explain those blanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
An interface block is not a complete program unit, just as any other fragment of Fortran code such as a DO loop is not a complete program unit. Therefore, it cannot be compiled by itself.
The interface block can be placed inside a module that is than USEd where needed, or the file with the interface block can be INCLUDEd where needed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
mecej4 wrote:
An interface block is not a complete program unit, just as any other fragment of Fortran code such as a DO loop is not a complete program unit. Therefore, it cannot be compiled by itself.The interface block can be placed inside a module that is than USEd where needed, or the file with the interface block can be INCLUDEd where needed.
I tried both ways. For example, placed the file with INTERFACE and END INTERFACE as a file to be INCLUDED. This ends up with all the routines as unresolved. Same result if I place MODULE and END MODULE around the file and add a USE command.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This ends up with all the routines as unresolved.
Of course! Interfaces are just that: descriptions of the interfaces to subprograms. The code for the subprograms is, presumably, in your libraries, and you have to link your code to those libraries.
Interfaces help the compiler to know how to pass arguments to the called subroutine. What to do with the arguments is up to the library code. Think of an interface as a phone number. When you call the number, there has to be someone at that phone number to receive the call.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I understand. But as noted by Steve, based on the dumpbin output the files are there. I also tried by removing the space in front of some of the routines as you note, still no improvement.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You could INCLUDE this file in the declarations section of each and every procedure that calls one of these library routines, or create a module and USE the module. You have to do this in each place these routines are called. You also need to specify the .lib as a source file or linker input.
If you do that and it still doesn't link, do you get exactly the same errors as before?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page