Cannot link a solution

Cannot link a solution

I have many unresolved links (error LNK2019)Could you help me to link project please ?in attachment I join build log file.Thank you!

AttachmentSize
Downloadapplication/octet-stream lanceur.log13.09 KB
14 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I moved your question from the Fortran forum as it seems you are using Intel C++ only.

Some general comments: You are using /force:unresolved and /nodefaultlib - these usually cause more problems than they solve. My guess is that you added them in an attempt to fix linking errors. Remove them.

You have two classes of unresolved reference errors. Some, such as __imp__calloc should be coming from the C run-time library. You did not show the compile command line, but I would guess that you are building a debug configuration but told the linker to not link to MSVCRTD.LIB - this will prevent access to the C library.

You also have references to user routines such as nc_get_var_short and NF_CREATE. These would be defined in some library you link to - while you have added /LIBPATH to tell the linker where to find libraries, you have not named any specific libraries to link to. You must name them under Linker > Additional Dependencies or add the libraries to your project as if they were source files.

Retired 12/31/2016

as fact there is 2 fortran projects (pasim.lib and interface.lib), netcdf share library and main C linked together.I added /force with hope to build the applicationand I used /nodefaultlib: MSVCRTD.LIB because I had so many errors with this lib.I hoped that this would resolve the problem but it is not the case.it is a debug configurationnc_get_.. and NF_CREATE... are netcdf routines defined in netcdf.incthis file is included in netcdf subroutines in pasim.lib asinclude 'netcdf.inc'then all subroutines are compiled and linked in a static lib and this lib is linked to main C program.in the project properties there are referencies on netcdf librariesand inLinker > Additional Dependencies I add pasim.lib and interface.libif I understand well I must also add netcdf.lib and netcdf_f90.lib too, is not it ?what should I do with MSVCRTD.lib ? if this lib is used there are hundreds other linker errors.thank you for help!

I think that your strategy of excluding libraries with the (sole?) objective of avoiding linker errors is flawed. You should analyze the requirements of your project and, for the debug or release configuration that you are building, choose the appropriate libraries which you think should be necessary and sufficient. If errors occur after doing so, one can analyze the errors.

Please do a "clean", verify your configuration, and build again. That will get rid of a messy situation with some objects built for debugging and some for not debugging, with embedded flags calling for linking incompatible libraries.

I did "clean" and re-build with all necessary libraries.Please, look at command lines of projects and build.log file
1 Fortran project - pasim.lib
/nologo /debug:full /Od /fpp /I"F:\WORK\win_validate\netcdf" /warn:interfaces /module:"Debug\..\modules" /object:"Debug\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /c
/OUT:"Debug/pasim.lib" /NOLOGO
2 Fortran project - interface.lib
/nologo /debug:full /Od /I"..\..\netcdf" /I"..\..\pasim\modules" /I"F:\WORK\win_validate\pasim\Debug\..\modules" /warn:interfaces /module:"Debug\" /object:"Debug\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /c
/OUT:"Debug/interface.lib" /NOLOGO

3 main C project - lanceur.exe/I"F:\WORK\win_validate\netcdf" /ZI /nologo /W3 /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D"_UNICODE" /D "UNICODE" /EHsc /RTC1 /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fp"Debug\lanceur.pch" /Fa"Debug" /Fo"Debug" /Fd"Debug\vc100.pdb" /Gd
/OUT:"F:\WORK\win_validate\Debug\lanceur.exe" /INCREMENTAL /NOLOGO /LIBPATH:"F:\WORK\win_validate\netcdf" /LIBPATH:"F:\WORK\win_validate\pasim\Debug" /LIBPATH:"F:\WORK\win_validate\interface\Debug" "pasim.lib" "interface.lib" "netcdf.lib" "netcdf_f90.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /MANIFEST /ManifestFile:"Debug\lanceur.exe.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"F:\WORK\win_validate\Debug\lanceur.pdb" /SUBSYSTEM:CONSOLE /PGD:"F:\WORK\win_validate\Debug\lanceur.pgd" /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X86

P.S.
the folder ..\lanceur\Debug contains netcdf dll files too

The log file shows two classes of errors. I can offer plausible reasons for these, but of course I do not know definitely since I have only seen what has been posted here.

1. The 'undefined external' messages are traceable to compiling some of the libraries from Fortran sources. When one uses the Intel Fortran compiler for Windows, by default, routine names are uppercased in the .OBJ and .LIB files. If they are called from C/C++ using lowercase names, unresolved references will occur ("symbole externe non rsolu"). See the /us option for the Fortran compiler.

2. If one or more of the sources contributing to the libraries "pasim.lib" "interface.lib" "netcdf.lib" "netcdf_f90.lib" were compiled with the /libs:dll or /MD comiler options, references to MSVCRTd.lib would be embedded in the corresponding libraries, and result in the 'duplicate definition' errors ("dj dfini(e) dans MSVCRTD.lib"). Either rebuild all your libraries with the same /libs: option or use linker options such as /nodefaultllib:MSVCRTd.lib.

for the second case :if I add/nodefaultllib:MSVCRTd.lib the following errors appears :1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _malloc import dans la fonction _Malloc 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _free import dans la fonction _Free 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _vprintf import dans la fonction _printfmpi 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _printf import dans la fonction _ncattputp 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _fopen import dans la fonction _lecture_param 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _exit import dans la fonction _lecture_param 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _fclose import dans la fonction _lecture_param 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _tolower import dans la fonction _getstr 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _atoi import dans la fonction _getint 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _atol import dans la fonction _getulong 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _sprintf import dans la fonction _histend 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement ___iob_func import dans la fonction _sechiba_call 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _fflush import dans la fonction _sechiba_call 1>lanceur_pasim_paral.obj : warning LNK4217: symbole dfini localement _fprintf import dans la fonction _main1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__malloc imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__free imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__vprintf imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__printf imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__fopen imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__exit imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__fclose imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__tolower imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__atoi imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__atol imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__sprintf imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp____iob_func imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__fflush imported 1>ipo : warning #11077: F:\WORK\win_validate\lanceur\Debug\lanceur_pasim_paral.obj: locally defined symbol __imp__fprintf imported

for the 1st case :all calls of these routines happens in Fortran project (pasim.lib)this project linked to the share library (netcdf.dll) using (netcdf.lib and netcdf_f90.lib)
in 'netcdf.inc' file these routines defined using lowercase names.in the fortran project I tried the both lower- and upper- case names to call the netcdf routines, nothing changes.

This thread covers the remaining question as to locally defined symbols being imported:

Locally Defined Symbol Imported.

It is slightly humorous that the messages are given in French first and then repeated (by IPO) in English.

You cannot fix the problem by changing routine names in your sources. Fortran is a case-ignorant language and the compiler converts all external names to uppercase. Thus, NF_CREATE, Nf_Create, nf_create and Nf_CrEaTe are all the same after compilation (_NF_CREATE for Windows-32). That is why the compiler option /us is provided.

If you want fine-grain control, you have available the non-standard directives such as

!DEC$ ATTRIBUTES C, ALIAS:'_ctxt':: CTXT

and the Fortran-2K C interoperability:

subroutine FTNROUTINE(fname, nlen) bind(c, name ='FtnRoutine')

However, use of these features is overkill for your case (not to mention unnecessary and involving a lot of effort).

Sorry i did not copy the errors : 1>lanceur_pasim_paral.obj : error LNK2019: symbole externe non rsolu __imp___time64 rfrenc dans la fonction _time 1>lanceur_pasim_paral.obj : error LNK2019: symbole externe non rsolu __imp__calloc rfrenc dans la fonction _Calloc 1>lanceur_pasim_paral.obj : error LNK2019: symbole externe non rsolu __imp__fgetc rfrenc dans la fonction _lecture_param 1>lanceur_pasim_paral.obj : error LNK2019: symbole externe non rsolu __imp__feof rfrenc dans la fonction _lecture_param 1>lanceur_pasim_paral.obj : error LNK2019: symbole externe non rsolu __imp__atof rfrenc dans la fonction _getfloat 1>lanceur_pasim_paral.obj : error LNK2019: symbole externe non rsolu __imp__fscanf rfrenc dans la fonction _main

for all fortran routines called from main C program I already rewrited fortran functions with bind(c, name='...') option, and in main C declared them as extern void ...but the current case is when I call external routine (netcdf) from Fortran project. and it does not work yet...

some remarks :I compiled the project with the old version of static netcdf.lib, the only additional conditions I used are/NODEFAULTLIB:"LIBCMTD.lib" and /MTd (multi_thread runtime lib)it is preferable for me to use the new shared library of netcdf, but as I've been mentioned before there are linker errors that I don't know how to resolve.thank you for your help !PS.the old static lib has bugs, NF_CREATE crashes.I would be very recognized if somebody could help link the project with the latest dynamic netcdf library.

>>...would be very recognized if somebody could help link the project with the latest dynamic netcdf library...

Could you create a small test project that reproduces the problem?

Note:a netcdf.lib file must be included.

If you providethe test projectsomebody could try to help you out.

Best regards,
Sergey

Leave a Comment

Please sign in to add a comment. Not a member? Join today