- 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
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
Made the file into a header file and added INCLUDEs in the needed routines. The lines within the header file are typically like
SUBROUTINE FMSIGT (NAME, VALUE)
!DEC$ATTRIBUTES C, REFERENCE, ALIAS:'fmsigt'::FMSIGT
CHARACTER *(*) NAME
INTEGER VALUE
END SUBROUTINE FMSIGT
to denote the C rountines stored in a .dll I've added the path to the .dll into the environmental PATH.
Error messages coming out relate to "unresolved external symbol" for each of the C rountines called in the fortran program and subrounties. VS2008 build log attached.
I've referenced the 2 needed librariesbut how does VS link to the .dll that contains the C rountines? Do I need to reference it in VS2008?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok - you are now correctly using the include files. However, I wonder if the .lib files are correct. Can you attach a ZIP of one to a reply here? If they are DLL import libraries they have no code.
As for the DLL, the way it works on Windows is that the the import library contains information the linker uses to set up the relationship to the DLL. You don't link to the DLL itself. When you run the program, Windows sees the DLL name and looks for it in its normal search paths.
- 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
Steve,
Did a "lib /list F:\Macro3d\FMS\fmsnogpu.lib" and it contains a number of lines each of which has fmsnogpu.dll. If I do a "dumpbin -exports F:\Macro3d\FMS\fmsnogpu.dll" it indicates 136 functions and then lists a bunch of C rountines on each line. I might assume that the lines in fmsnogpu.lib map the corresponding .dll (different .dll for each is possible) where the C routine is contained (good assumption?). If this is correct, Windows should know the needed .dll for each C rountine and with the PATH set find the dll.
There is an additioal .lib input (fmsnoshr.lib). I don't know what purpose it serves but I've attached it, just in case it might help figure this out.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
fmsnogpu.lib is a DLL import library. It has some of the routines your program is looking for, but not all, such as fmsini. fmsnoshr-lib is a static library that defines many of the same routines - it does have fmsini.
Still, I am puzzled that your build did not find fmspsh since it is in fmsnogpu.lib. Please do one more thing. In your project, go to the Linker > General property page and set the "Show progress messages" property to "Show all progress messages", then try the link again. Attach the new buildlog.htm (as a zip) so I can see what it is doing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh, one thing is really odd - the library shows in the middle of the link line, not at the end where I might expect it. Please also attach a ZIP of the .vfproj file.
- 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
Got it! The problem is that you added the FMS libraries in the linker property Advanced > Import Library. I can sort of see why you may have thought that was the right place, since one of these libraries is indeed an import library, but if you read the inline help for that property it says "Specifies which import library to generate". This isn't what you want and in fact has no effect at all in this build.
Move this value to Linker > Input > Additional Dependencies and it will be much happier.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bingo! How did you figure that out? Compiles fine now.
With great flexibility (such as VS) comes even more changes to screw it up.
Thanks Steve!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, remember that I said that the log showed the libraries in an odd place in the link line. Then when you showed the log with "progress" messages, I saw that the FMS libraries were never even looked at. So I asked for the .vfproj file to see where you were specifying these and found them in the wrong place. I did get confused a bit before I realized that you had these in one configuration only - Release x64.
May I also suggest that you change your "Display Name" for Intel Developer Zone to be something other than your email address? You should be able to do this through the "Dashboard" (click on the triangle to the right of your name in the upper right.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve, changed the dashboard.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Opps, not out of the woods yet.
Build doesn't complete the link. There are 5 C rountines not identified in the fnamefile.dll and these produce the unresolved externals. The supplier suggested to just change the calls from CAPITALIZED FILE NAMES (call XYZ) to lower case file names (call xyz). This makes sense but doesn't work. I'm wondering if I have something else screwed up in my project properties.
Attached is both the build.log and the vfproj again for my current setup. They look OK to me but something is amiss.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The supplier suggest to just change the calls from CAPITALIZED FILE NAMES (call XYZ) to lower case file names (call xyz).
Let's not confuse file names and subprogram names.
Intel Fortran has a default case for the names of external symbols (routine names, module names, common block names, etc.), and the .OBJ files contain names with that default regardless of the case used in the source (Fortran is case-insensitive except w.r.t. the contents of character variables). See if the /names:lowercase compiler option will help resolve your problems.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please do not use /names. Simply changing the names in the Fortran source won't help. What this tells me is that either the include file/module doesn't declare those routines, or you forgot to include/use it in the main program.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »