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:
Any help in troubleshooting would be GREATLY APPRECIATED!!!!! I'm seriously racking my brain on this one....
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
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.
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.
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.
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.
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.
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.
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?
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.
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.)
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
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.
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.
I don't understand why the linker isn't searching the libraries. Please upload a new buildlog and I will look at it tomorrow.
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.
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.
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.