LNK2019, LNK2001

[wen]

I am using Intel composer XE 2011 Update 3 (w_fcompxe_2011.3.175) on Microsoft Visual Studio 2008 shell. In this system, I tried to build a project, which was built successfully in another PC, which runs IVF vs. 9 or 10 under MS VS 2005.

I got a Linker error

error LNK2019: unresolved external symbol_for_write_seq_lis referenced in function _ABC_mp_PRINTABC

There is a Subroutine PrintABC() in Module ABC. Inside Subroutine PrintABC, there are only nine PRINT statements and one IF block. In the IF block, there are another five PRINT statements. There is nothing else. It seems that the error is associated with print statements. Could you tell me why those print statements would cause the error of unresolved external symbol_for_write_seq_lis.

I also got seven

error LNK2001: unresolved external symbol_for_write_seq_lis

for a linked library, which has been used for another project in this system without problem.

Please help.

[mecej4]

Instead of manipulating the PRINT statements, consider doing "clean and rebuild". The error messages suggest that you are trying to link a project in which not objects/libraries were built with the same compiler.

If the project is small and simple, I suggest, recreate the project with your current VisualStudio in a fresh directory into which you copy your existing source files only.

[jeremy_h]

If all else fails, use DUMPBIN on your link objects, libraries and exe's. If necessary, compare these to the DUMPBIN outputs using your old compiler.

I have frequently found exe's that would not link with IVF because of "missing symbols", but the missing symbols are actually in dead code. If you have code such as IF (FALSE) THEN, and a missing symbol in the branch, CVF/VS6 appears to exclude it by default whereas IVF/VS9 appears to include it. If this is your problem, use optimize for size to force IVF/VS9 to exclude unreachable code.

[Steven_L_Intel1]

I don't think that this particular routine has changed its name since version 8. I'm going to guess that this Fortran library is being linked into a mixed-language application where the main program is C or C++. Are there other error messages such as missing libraries? Can you show us the build log of the build that failed?

I will comment that it is not supported to compile using one version of Intel Fortran and link to libraries of an older version. This can also cause linking errors, but probably not this one.

[wen]

Thank you all.

I tried Clean and Rebuild and got the same errors.

The project depends on two projects, libCwrCommon and F2KCLI, which I have been used successfully for other projects. In additional to libCwrCommon and F2KCLI, I specified netCDF.lib as one of the Additional Dependencies in Linker Input. This netCDF.lib is obtained from some other people and cause problem from time to time. I could not build netCDF.lib myself.

I dont know how to use DUMPBIN on your link objects, libraries and exe's.

Attached please find the build log BuildLog-12.0.3-NG.htm and a copy of what came out to the error list, Error_List_12.0.3-NG.doc.

I had the same project built successfully under IVF 9.1 in another PC, which I call PC2. Also attached for your reference are the build log VuildLog-9,1-good.htm and a copy of its associated output, output-9.1-good.doc.

[Steven_L_Intel1]

The problem is that your project has the /NODEFAULTLIB option set. In Visual Studio this is the project property Linker > Input > Ignore all default libraries > Yes. Change that property to No and rebuild.

You might have set this because of this message which I see in the 9.1 build:

Link: executing 'link'
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

That is usually the wrong thing top do when dealing with a library type conflict. Instead, make sure that all your code is compiled with the same type of run-time library (static vs, DLL, debug vs. non-debug).

[wen]

Thank you, Steve.

Yes, I saw the warning message
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
and set to the /NODEFAULTLIB option.

Now, followingyour advise, I reset "Ignore all default libraries"to "Yes" and ignore that "warning LNK4098."Then, all those earlier LNK2019 and LNK2001 errorsdisappeared.

But, there arose some other LNK2019 and LNK2001 errors such as:
libCwrCommon.lib(hlnetcdfops.obj) : error LNK2001: unresolved external symbol _NF_INQ_VARID@16
which is related to the library netCDF I specified in "Linker Input." All those external sybols NF_XXXXXX are related to the library netCDF.

Attached please find the build log, BuildLog.htm.

Could you tell why I have this kind of errors while I built the project successfully under IVF 9.1 in the other PC?

[wen]

By the way, I double checked. I use static libraries only without DLL and I use Debug, no Release,for all moduli.

[mecej4]

libCwrCommon.lib(hlnetcdfops.obj) : error LNK2001: unresolved external symbol _NF_INQ_VARID@16

This message indicates that you have some libraries containing objects compiled with the Stdcall calling convention, and others compiled with the Cdecl convention.

It is possible, when necessary, to successfully build an application with a mixture of calling conventions, but it is much easier if only one convention is used.

If you have the sources to libCwr....lib, I suggest that you rebuild it with the default calling convention of IFort.

[wen]

Thank you.

I have never used IFort in DOS commend line. I just use Microsoft Visual Studio to build projects. I dont know where to set either the Stdcall calling convention or Cdecl convention. I cleaned the project and rebuild the project and got the same error messages. I also tried clean and rebuild in Release configuration and got the same error messages.

[Steven_L_Intel1]

My guess is that the netCDF library you picked up was built for Compaq Visual Fortran. You need one that is made for Intel Visual Fortran. I would expect exactly the same errors in 9.1 if you were using the same library.

[wen]

That bothers me. I am using exactly the same netCDF.lib in both 9.1 and 12.0.3 environments.

[mecej4 · Accepted solution]

Searching for "libCwrCommon.lib", I found this link DYRESM-CAEDYM compilation using IVF GUI . In several places, it tells you to

c. Click Fortran > External Procedures > Calling Convention > CVF
d. Under Fortran > Command Line add /iface:mixed_str_len_arg

I think that these instructions may have been followed in building your version of libCwrCommon.lib. If so, and the version of the NetCDF library that you have is Intel Fortran compatible, there is a mismatch.

[wen]

Okay, I did have /iface:cvf in Calling convention for while it is Default in that successful IVF 9.1 run. (I used to have trouble without setting /iface:cvf.) I had it changed to Default in this IVF 12.0.3 run. And it worked. Bravo!

Thanks a lot.