- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a C wrapper that has always been 32-bit. It calls a FORTRAN subroutine. This FORTRAN subroutine is in a FORTRAN library (MyFortranLibrary_lib.lib)
The problem is with the C Wrapper. When I compile the C Wrapper (and thus try to link it to this 64-bit FORTRAN library), i get A LOT of errors of type "error LNK2001: unresolved external symbol for _something_something_somth
Here's a sample of the these LNK errors:
MyFortranLibrary_lib.lib(S
1>MyFortranLibrary_lib.lib
1>MyFortranLibrary_lib.lib
1>MyFortranLibrary_lib.lib
1>MyFortranLibrary_lib.lib
1>MyFortranLibrary_lib.lib
1>MyFortranLibrary_lib.lib
1>MyFortranLibrary_lib.lib
Any help in troubleshooting would be GREATLY APPRECIATED!!!!! I'm seriously racking my brain on this one....
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You probably have VC++ configured incorrectly to reference the Intel libraries for x64. See https://software.intel.com/en-us/articles/configuring-visual-studio-for-mixed-language-applications
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Steve: first, wow! It's an honor for you to assist us in this. I have carried out the instructions in the link that you provided. We are working with VS2008 and Intel Visual Fortran 11.1.048.
After updating the Library Directories, I issued a fresh Rebuild. I still encounter the same number of LNK 2001s.
Any further advice or information requests from us are greatly appreciated.
Edit: Please note that I revised $(IFORT_COMPILER11)compiler\lib\intel64 to $(IFORT_COMPILER11)lib\intel64. I subsequently rebuit the solution, and I am still encountering the LNK 2001 errors. I apologize for the error.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok. Next thing is to make sure that the project property Fortran > Libraries > Disable Default Library Search Rules is set to No for that configuration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for sticking with us. *In the wholly separate FORTRAN project* (i.e., the source code used to build the FORTRAN library), I have confirmed that the FORTRAN > Libraries > Disable Default Library Search Rules is set to No. As a sanity check, I issued a Rebuild (Release x64) and copied the newly built FORTRAN library into the (separate) directory containing the C++ wrapper .sln file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a suspicion that you are (unintentionally?) attempting to use the previously built 32-bit library MyFortranLibrary_lib.lib when building your 64-bit target.
To verify this, at least for a couple of days use distinct names such as MyFtn32lib.lib and MyFtn64lib.lib, and change the references to MyFortranLibrary_lib.lib to MyFtn64lib.lib in your 64-bit projects and solutions. Clean and rebuild, and let us know what you see.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't think so, mecej4. The names that are not found don't have a leading underscore which means they are built for 64-bit.
Let's do this. Set the C++ project's property Linker > General > Show Progress to Display all Progress Messages and do a link. Zip the C++ build log and attach it here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve, the zip is attached. Many thanks to you guys for the help on this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Strange. I can see the /DEFAULTLIB directives for the Fortran libraries being recognized but the linker never looks at them. I don't spot a linker option that disables this.
Here's a workaround. In the Linker > Input > Additional dependencies property, add:
ifconsol.lib libifcoremt.lib libifport.lib libmmt.lib libirc.lib svml_disp.lib ifwin.lib
and see what that gets you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found something in the build-log attached to #8 that appeared out of order:
... Searching libifcoremt.lib: Searching libifport.lib: Searching libmmt.lib: Searching libirc.lib: Searching svml_disp.lib: Searching IFWIN.LIB: Searching skeylib64.lib: Searching FB-MultiPier_lib.lib: Finished searching libraries Finished pass 1
Since the user library FB-.. is searched at the very end, RTL routines used in that library would go unsatisfied -- correct?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve, I added the additional dependencies, but I'm still seeing the same number of LNK2001 errors. The updated (verbose) build log is attached.
mecej4, also thanks for your help; I defer to your guys' expertise on how to proceed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmm - I missed that. Yes, it may be an ordering thing. How do you have FB-Multiplier_lib specified in the project? What if you add it at the beginning of the Additional Dependencies list? (Need a path there or in Additional Library Directories.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As per your suggestion, I've moved our library to the front of the list of Additional Dependencies, but no luck. Same list of compile errors as previously.
The entire list of Additional Dependencies is as follows (with our library moved to the front of the list):
MyLibrary_lib.lib skeylib64.lib ifconsol.lib libifcoremt.lib libifport.lib libmmt.lib libirc.lib svml_disp.lib ifwin.lib
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It sort of looks to me as if the library directories aren't set properly, even though it looks as if you did. Try adding the explicit path to $(IFORT_COMPILER11)lib\intel64 into Additional Library Directories.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Steve, thanks again for sticking with us, and sorry for the delay.
I have replaced the macro with the following path:
C:\Program Files (x86)\Intel\Compiler\11.1\048\lib\intel64
Unfortunately, I still encounter the LNK2001s. Sorry for the difficulties, and we're all ears for any further suggestions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't understand why the linker isn't searching the libraries. Please upload a new buildlog and I will look at it tomorrow.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Very much appreciated; we're going crazy over this issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I have read the build-log from #17 correctly, you (or a build script or VS) called the MS C compiler cl.exe to do the linking. That is not the best way to build when you have a mix of Fortran and C/C++ objects to link. Use the compiler driver ifort.exe to do the linking, or use link.exe directly with the correct arguments and options.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks mecej4, I'm googling how to tell VS2008 to use ifort.exe instead of cl.exe. I welcome your input on how to make that switch as well; sorry for the ignorance on my part.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In VS, that doesn't matter. Even in a Fortran project we use link.exe to do linking. The only issue might be if you use /Qipo in which case the Intel xilink prelinker gets used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve, thanks for the late-in-the-day follow up. We've learned a lot from the assistance, and we're grateful to keep trying fixes as they're offered. If it's of any use:
1. Specific to the wrapper, if I comment out the single call to the FORTRAN library, then I can successfully build the (albeit neutered) wrapper.
2. Specific to the FORTRAN project, by changing select settings (e.g., multithread to qwin) I am able to successfully build an x64 release exe (no wrapper involved; but not an acceptable workaround for us).
I interpret these items as signs that we're on the right track by treating the wrapper (and specifically, the linking) as the culprit.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page