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