Unresolved external symbols

[Ashley_Weinstein]

When I attempt to compile some legacy code I first get an error that the linker cannot find DFWIN.LIB (from CVF days). So I ignore that specific library. Then I get another file that's a problem too. So I walk down the line and ignore the libraries that it's looking for. Overall the following 5 libraries are ignored:

dfwin.lib, dfor.lib, libc.lib, dfconsol.lib, dfport.lib

I have the libraries the linker wants (from a computer that still has CVF 6.6c installed on it) and I added them into the project solution but this did not resolve the issue. It began to have duplicate definitions errors, between the CVF version of the file and IVF version of the file.

After ignoring all 5 libraries I get the following error below. To me it appears that the functions that PSWPTH is looking for are Fortran intrinsic functions and since this is legacy code these intrinsic functions must be from CVF.

Linking...
Creating temporary file "RSP1.rsp" with contents
[
 /OUT:"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe" /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:"dfwin.lib" /NODEFAULTLIB:"dfor.lib" /NODEFAULTLIB:"libc.lib" /NODEFAULTLIB:"dfconsol.lib" /NODEFAULTLIB:"dfport.lib" /MANIFEST /MANIFESTFILE:"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Debug/EFPS6.pdb" /SUBSYSTEM:CONSOLE kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MACHINE:I386 "Debug/RSIDECNFG.obj" "Debug/PYGERA.obj" "Debug/fbxdrv.obj" "Debug/PyrolmLink.obj" "Debug/RSISPY.obj" "Debug/EFPSVersionInfo.res" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\GUIlink.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\slmpsw\\lsapiw32.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\PASSWD.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\GEN9306.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\TLEX.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\Flowsheet.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\SPYRO6.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\FIREBOX.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\LMFAC.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\CONVEC.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\NLSECURE.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\KIN9306.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\AUXILL.lib" "k:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Debug\\EFPS6_lib.lib"
]
Creating command line "Link @"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Debug\\RSP1.rsp""

Link: executing 'link'
EFPS6_lib.lib(Pyrolm.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol _GETENVQQ@16 referenced in function _PSWPTH
NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol _for_f90_index@20 referenced in function _PSWPTH
NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol _for_len_trim@8 referenced in function _PSWPTH
NLSECURE.lib(PSWPTH.OBJ) : error LNK2001: unresolved external symbol _for_len_trim@8
NLSECURE.lib(PSWPTH.OBJ) : error LNK2001: unresolved external symbol _for_len_trim@8
NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol __OtsMoveMinimum referenced in function _PSWPTH
NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol __OtsFill referenced in function _PSWPTH
NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol _SPLITPATHQQ@40 referenced in function _PSWPTH
K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe : fatal error LNK1120: 6 unresolved externals


EFPS6 - 9 error(s), 4 warning(s)

So I look into the static library containing PSWPTH.f and I see that it's using DFWIN and using DFLIB. I comment both of those out, recompile the *.lib file and reinsert it into the main project. I compile and get the following:

Linking...
Creating temporary file "RSP1.rsp" with contents
[
 /OUT:"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe" /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:"dfwin.lib" /NODEFAULTLIB:"dfor.lib" /NODEFAULTLIB:"libc.lib" /NODEFAULTLIB:"dfconsol.lib" /NODEFAULTLIB:"dfport.lib" /MANIFEST /MANIFESTFILE:"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Debug/EFPS6.pdb" /SUBSYSTEM:CONSOLE kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MACHINE:I386 "Debug/RSIDECNFG.obj" "Debug/PYGERA.obj" "Debug/fbxdrv.obj" "Debug/PyrolmLink.obj" "Debug/RSISPY.obj" "Debug/EFPSVersionInfo.res" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\GUIlink.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\slmpsw\\lsapiw32.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\PASSWD.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\GEN9306.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\TLEX.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\Flowsheet.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\SPYRO6.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\FIREBOX.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\AUXILL\\Release\\AUXILL.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\LMFAC.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\CONVEC.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\NLSECURE.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\KIN9306.lib" "k:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Debug\\EFPS6_lib.lib"
]
Creating command line "Link @"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Debug\\RSP1.rsp""

Link: executing 'link'
EFPS6_lib.lib(Pyrolm.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
AUXILL.lib(PSWPTH.obj) : error LNK2019: unresolved external symbol _GETENVQQ@16 referenced in function _PSWPTH
AUXILL.lib(PSWPTH.obj) : error LNK2019: unresolved external symbol _GETMODULEFILENAME@16 referenced in function _PSWPTH
AUXILL.lib(PSWPTH.obj) : error LNK2019: unresolved external symbol _SPLITPATHQQ@40 referenced in function _PSWPTH
K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe : fatal error LNK1120: 3 unresolved externals


EFPS6 - 4 error(s), 4 warning(s)

I toggled DFLIB on and off. Now I get all 9 original errors regardless. Any help would be appreciated!

[Steven_L_Intel1]

You must recompile all Fortran code - you are linking in objects or libraries built with CVF. That can't be mixed with Intel Fortran.

[Ashley_Weinstein]

OK, so I'm looking into this and it looks like those libraries I'm ignoring have the references for the calls that are missing.

For example: GETENVQQ is in DFPORT.lib which is now IFPORT.lib.

I tried adding USE IFPORT to PSWPTH.f, recompiling the library, then recompiling the project with the library in it.

No dice, still the same 9 errors =(

[Ashley_Weinstein]

Steve, I've recompiled all the old CVF code in IVF then rebuilt all the libraries.

The AUXILL.lib (which contains PSWPTH.f) is built using IVF from the existing source code. Then AUXILL.lib is used in other project which has also been updated to IVF.

This solution was working in IVF before but now I'm having these particular issues. It's frustrating that something would work 2 weeks ago then not work now.

Thanks for your advice!

[Steven_L_Intel1]

You are still linking in libraries compiled with CVF. Maybe you're not pulling in your rebuilt library.

[Ashley_Weinstein]

What I don't get is how can AUXILL.lib compile and build fine (with PSWPTH.f and those GETENVQQ and SPLITPATHQQ functions in it), yet when I add the *.lib into another IVF project solution I get the errors. So confusing!

[Ashley_Weinstein]

I opened up an old CVF *.dsw project and converted all the source files over to IVF in a *.vfproj. Then in the *.vfproj environment I recompile and build AUXILL.lib.

Then I take that AUXILL.lib and add it into another *.vfproj. That's when I get these errors.

You must be right about the CVF/IVF mixing. I've just got to figure out where it's occurring. If AUXILL.lib is building properly then it must be something with the other *.vfproj....

[Ashley_Weinstein]

I think I know what the problem is. It must be NLSECURE.lib that is causing the errors. I'll have to find the source code for that and recompile it in IVF.

[Ashley_Weinstein]

Nope, this isn't it. Another project in IVF (same source code w/ exception of the two new files I've created) compiles and builds just fine with NLSECURE.lib.

[Steven_L_Intel1]

See my reply to another user here - you have a similar problem. Do what I asked there and attach the build log (don't insert it inline, it will be big) You might even want to ZIP it first.

[TimP]

You have references to CVF linkage of Fortran run-time functions. Those probably come from the libraries (you could check where those functions reside). This raises the possibility those libraries were made to require Compaq Fortran (which went off support over 10 years ago).
Besides switching to dynamic linkage, as Steve said, you will probably have to try building everything with /iface:cvf until you can get the libraries remade. That still would likely fail if the required run-time functions are actually from CVF.

[Steven_L_Intel1]

There are other oddities, however. PSWPTH in NLSECURE.LIB seems to be the source of all of them and from looking at the symbols it references, this one souce was compiled with CVF (not just ifort with /iface:cvf.) You need to recompile it with Intel Fortran.

[Ashley_Weinstein]

Unfortunately I don't have the original source code for NLSECURE.lib so it appears I might be hosed.

[Ashley_Weinstein]

The big problem is that I do not have the source for two static libraries that are CVF-era (NLSECURE.lib and another one).

[Steven_L_Intel1]

Yes, that is a problem. You won't be able to solve that by juggling libraries. The best you can do is build a DLL from them, using a .DEF file to export the routine names you want. You'd have to do this with CVF to satisfy the external references (link to the static form of the CVF libraries). Then you could call the entries in the DLL as long as you weren't trying to share I/O units or pass deferred-shape arrays.

[Ashley_Weinstein]

It frosts me that in one case the compiler accepts a set of source code in one project, then in another project containing the same source code the compiler barfs and spits out these unresolved external symbol errors.

How can the compiler complain about unresolved external symbol _GETENVQQ@16 (PSWPTH.obj) in one instance and then not complain about it in another instance?

[IanH]

The compiler isn't barfing - those messages are coming from the linker.

(In #5 you say "What I don't get is how can AUXILL.lib compile and build fine...".

When you build a library the librarian utility normally just builds a simple archive of all the bits of object code that were generated from the source code in the project. The librarian utility (which on Windows is actually the linker moonlighting for some extra cash on the side) doesn't go through each piece of object code and make sure that it can satisfy all the various symbol references - in many cases that would defeat the purpose of building a library.

It is not until the final link stage (when the actual EXE or DLL is built) that the linker must resolve all the symbol references in the bits of object code that are being linked together.

So building a lib is not a sufficient test that all is well.

If you had two projects that were both generating EXE's (or DLL's), and one was failing while the other succeeded, then that's a different story, one that would explore differences between the projects.)

[Ashley_Weinstein]

Here is an example of one problem I am having linking C++ files and Fortran files:

I have a GUILink_lib that contains a header file and two C++ files.

In the GUILinkC.c file (under the GUILink_lib project) there is a function called GUIDay with code as follows:

/*
* Function name: GUIDay
* Description : In a multi-day run, this is called with the number of the
* current simulation day, starting at day 1. In a single day
* simulation, it must also be called with argument 1.
* Arguments I: int DayNumber - the number of the day.
*/
void
GUIDay(int DayNumber)
{
GUICurrentDay = DayNumber;
}

Then in the Fortran *.lib project, X_lib, there is GUILinkF.f which defines a subroutine GUIDAY that relays to the C++ function above, with code as follows:

C
C Function name: GUIDAY
C Relays to : GUIDay(int DayNumber)
C Description : Assign the number of the day currently being processed.
C Arguments : INTEGER*4 DAY - the day number of the current run.
C
SUBROUTINE GUIDAY(DAY)

IMPLICIT NONE

INTEGER*4 DAY

INTERFACE
SUBROUTINE GUIDAYC(DAY)
!DEC$ ATTRIBUTES C, ALIAS:'_GUIDay' :: GUIDAYC
INTEGER*4 DAY
END SUBROUTINE GUIDAYC
END INTERFACE

CALL GUIDAYC(DAY)

END


The project is set up as follows:

MainProgram (Fortran *.exe)
X_lib (Fortran *.lib)
GUILink_lib (C++ *.lib)
SlmpswC_lib (C++ *.lib)

The two C++ projects are added to the overall project by choosing Add New Project -> Win32 -> Win32 Project. These two static libraries are compiled first, followed by X_lib then MainProgram.

After compilation the linker has unresolved external symbols from the Fortran GUILink.f file to the GUILink.c file.

Any thoughts? I understand that in this new environment C++ and Fortran files must be compiled separately in different projects but that a solution can contain multiple projects in a user-specified order. I think I have set this up properly.

Is there an issue with the declaration calling convention?

[IanH]

Are you actually using C or C++? If the latter, then you need extern "C" on the definition. I think though that Microsoft's C++ compiler sanely regards files ending in .c as C files by default.

Perhaps this is what you have done - but rather than setting compilation order you should be setting project dependencies (for example, perhaps the MainProgram exe depends on X_lib). An appropriate build order is an outcome of having the dependencies set correctly, manual ordering beyond that is simply for build convenience. The process for setting dependencies is similar to that for build order (it is simply a different tab on the same dialog) - right click on a project in the solution explorer and select "Project Dependencies".

If static libraries are part of a dependency chain then you can also decide whether you want to archive all the subordinate libraries into one big library as part of the build step. To do this, in the project properties set Librarian > Link Library Dependencies to Yes (a similar Link Library Dependencies setting exists for Fortran exe's and dll projects, but it is set to Yes by default). If you don't do this, then the top level exe or DLL needs to explicitly have all the subordinate libraries in its list of dependent projects.

If you are using VS2010 and have C++ project that depends on a Fortran library, then you may (will?) need to explicitly list the name of the Fortran library in the linker properties of the C++ project.

The Fortran 2003 standard introduced new features into the language to assist with "inter-operating" between Fortran and C. If you use these new features, the source code connection between Fortran and C will be portable and considerably more robust. I'd rewrite your interface block to be:

[fxfortran] INTERFACE SUBROUTINE GUIDAYC(DAY) BIND(C, NAME='GUIDay') USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_INT IMPLICIT NONE INTEGER(C_INT), INTENT(IN), VALUE :: DAY END SUBROUTINE GUIDAYC END INTERFACE [/fxfortran] If the subroutine in that interface was renamed to GUIDAY, popped into a module that was then used where appropriate you could eliminate the need for your Fortran wrapper subroutine.

INTERFACE
SUBROUTINE GUIDAYC(DAY)
!DEC$ ATTRIBUTES C, ALIAS:'_GUIDay' :: GUIDAYC
INTEGER*4 DAY
END SUBROUTINE GUIDAYC
END INT[fortran] INTERFACE SUBROUTINE GUIDAYC(DAY) BIND(C,NAME='GUIDay') USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_INT IMPLICIT NONE INTEGER(C_INT), INTENT(IN), VALUE :: DAY END SUBROUTINE GUIDAYC END INTERFACE [/fortran] ERFACE

[mecej4]

I assembled a self-contained example from the pieces that you provided. I added a trivial main program in C, and it works as expected (see below). Therefore, any problems that you still have are related to mismatched calling conventions, especially concerning libraries obtained from others and containing routines required to be called with stdcall protocol, and complications in your build procedure.

The Fortran part: exactly as you gave it.
The C function: Add to what you gave:

extern int GUICurrentDay;

The C main program:

[cpp]#include int GUICurrentDay=123456789; extern void GUIDay(int); main(){ printf("GUICurrentDay = %dn",GUICurrentDay); GUIDay(987654321); printf("GUICurrentDay = %dn",GUICurrentDay); } [/cpp] Compile and link:

[bash]T:lang> ifort /MD /O2 guiday.f T:lang> icl /O2 /MD uguiday.c guiday.obj guidayc.c [/bash] Results:

[bash]T:lang>uguiday GUICurrentDay = 123456789 GUICurrentDay = 987654321 [/bash]

[Ashley_Weinstein]

Hi Ian,

Oops, what I meant by compiling order really is Project Dependencies. I set up the solution such that the Fortran exe MainProgram is dependant on Fortran static library x_lib and x_lib is in turn dependant on two other C++ static libraries in the same project. I assume that the projects are compiled in order of dependency.

I'll check on the status of Link Library Dependencies and make sure it is set to Yes.

I am using VS2008 and fairly new to programming.

So what you are recommending are two options:
1)Modify the INTERFACE block as you suggest and see if that resolves the Fortran/C linking issue
2) I rename theFortran GUIDAYCsubroutine to GUIDay, and then instead of using an INTERFACE command, instead put the subroutine into a MODULE block, then use that MODULE as needed. What is the syntax for using a MODULE block?

Thanks for the help!