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

Error LNK2001: Unresolved external symbol when calling a FORTRAN subroutine in a FORTRAN 64-bit library from a 64-bit C Wrapper

Michael_D_7
Beginner
3,752 Views

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).  This FORTRAN library file has also always been 32-bit. Everything has always worked fine.  However, I have recently changed both the FORTRAN library and the C Wrapper from 32-bit to 64-bit.  I have done this by simply changing the "Active Solution Platform" setting in visual studio from "win32" to "x64" for the C Wrapper and the corresponding setting in the FORTRAN library TO x64. The FORTRAN library compiles fine, without error.

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_somthing..... So it would appear that there is something further I must do to make things "play nice" between the C Wrapper and FORTRAN library, in the 64-bit world.

Here's a sample of the these LNK errors:

MyFortranLibrary_lib.lib(SomeObject1.obj) : error LNK2001: unresolved external symbol for_check_mult_overflow64
1>MyFortranLibrary_lib.lib(SomeObject2.obj) : error LNK2001: unresolved external symbol for_check_mult_overflow64
1>MyFortranLibrary_lib.lib(SomeObject1.obj) : error LNK2001: unresolved external symbol for_alloc_allocatable
1>MyFortranLibrary_lib.lib(SomeObject2.obj) : error LNK2001: unresolved external symbol for_alloc_allocatable
1>MyFortranLibrary_lib.lib(SomeObject1.obj) : error LNK2001: unresolved external symbol for_dealloc_allocatable
1>MyFortranLibrary_lib.lib(SomeObject3.obj) : error LNK2001: unresolved external symbol for_write_seq_fmt
1>MyFortranLibrary_lib.lib(SomeObject4.obj) : error LNK2001: unresolved external symbol for_write_seq_fmt
1>MyFortranLibrary_lib.lib(SomeObject5.obj) : error LNK2001: unresolved external symbol for_write_seq_fmt

Any help in troubleshooting would be GREATLY APPRECIATED!!!!! I'm seriously racking my brain on this one....

0 Kudos
22 Replies
Steven_L_Intel1
Employee
3,254 Views

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

0 Kudos
Michael_D_7
Beginner
3,254 Views

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. 

x64-libraries_0.PNG

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.

0 Kudos
Steven_L_Intel1
Employee
3,254 Views

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.

0 Kudos
Michael_D_7
Beginner
3,254 Views

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.

FORTRAN-project-libraries.PNG

0 Kudos
mecej4
Honored Contributor III
3,254 Views

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.

0 Kudos
Steven_L_Intel1
Employee
3,254 Views

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.

0 Kudos
Michael_D_7
Beginner
3,254 Views

Steve, the zip is attached. Many thanks to you guys for the help on this.

0 Kudos
Steven_L_Intel1
Employee
3,254 Views

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.

0 Kudos
mecej4
Honored Contributor III
3,254 Views

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?

0 Kudos
Michael_D_7
Beginner
3,254 Views

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.

0 Kudos
Steven_L_Intel1
Employee
3,254 Views

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.)

0 Kudos
Michael_D_7
Beginner
3,254 Views

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

 

0 Kudos
Steven_L_Intel1
Employee
3,254 Views

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.

0 Kudos
Michael_D_7
Beginner
3,254 Views

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.

0 Kudos
Steven_L_Intel1
Employee
3,254 Views

I don't understand why the linker isn't searching the libraries.  Please upload a new buildlog and I will look at it tomorrow.

0 Kudos
Michael_D_7
Beginner
3,254 Views

Very much appreciated; we're going crazy over this issue.

0 Kudos
mecej4
Honored Contributor III
3,254 Views

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.

0 Kudos
Michael_D_7
Beginner
3,254 Views

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.

0 Kudos
Steven_L_Intel1
Employee
3,254 Views

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.

0 Kudos
Michael_D_7
Beginner
2,694 Views

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.

0 Kudos
Reply