run-time error

[coolweather]

I have a fortran project which is linked to dll library (netcdf) and this dll library calls other dlls at runtime.

The fortran project builds without errors. But at run-time it cannot be loaded. And I don't know why!

I tried different PCs and different compilators versions.

Perhaps, the simplest way to give Command lines of these projects.

fortran project (calls netcdf)

/nologo /debug:full /Od /fpp /I"F:\\WORK\\win_validate\\netcdf\\v4.1.3" /I"C:\\Documents and Settings\\javital\\Mes documents\\Downloads\\netcdf\\netcdf-4.1.3-win-dev\\netcdf-4.1.3-curl-fortran\\f90" /warn:interfaces /names:lowercase /assume:underscore /module:"Debug\\\\" /object:"Debug\\\\" /Fd"Debug\\vc100.pdb" /traceback /check:bounds /libs:dll /threads /dbglibs /c

/OUT:"F:\\WORK\\win_validate\\netcdf\\v4.1.3\\nctest.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"F:\\WORK\\win_validate\\netcdf\\v4.1.3" /MANIFEST /MANIFESTFILE:"F:\\WORK\\win_validate\\netcdf\\v4.1.3\\nctest.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"F:\\WORK\\win_validate\\netcdf\\v4.1.3\\nctest.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"F:\\WORK\\win_validate\\netcdf\\v4.1.3\\nctest.lib" netcdf.lib

c++ project (netcdf library)

/I"." /I"F:\\WORK\\netcdf_413\\netcdf-4.1.3-curl-fortran\\win32\\NET\\" /I".." /I"..\\..\\..\\libsrc4" /I"..\\..\\..\\libsrc" /I"..\\..\\..\\libdispatch" /I"..\\..\\..\\libncdap3" /I"..\\..\\..\\fortran" /I"..\\..\\..\\oc" /I"..\\..\\..\\include" /I"..\\..\\..\\..\\include\\hdf5" /I"..\\..\\..\\..\\include" /Zi /nologo /W1 /WX- /O2 /Oy- /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "CURL_STATICLIB" /D "NETCDF_EXPORTS" /D "DLL_NETCDF" /D "DLL_EXPORT" /D "pgiFortran" /D "NC_DLL_EXPORT" /D "USE_DISPATCH" /D "H5_HAVE_WINDOWS" /D "USE_NETCDF4" /D "_VC80_UPGRADE=0x0710" /D "_WINDLL" /D "_MBCS" /Gm- /EHsc /MT /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fp"Release\\netcdf.pch" /Fa"Release\\" /Fo"Release\\" /Fd"Release\\vc90_netcdf.pdb" /Gd /analyze- /errorReport:queue

/OUT:"F:\\WORK\\netcdf_413\\netcdf-4.1.3-curl-fortran\\win32\\NET\\Release\\netcdf.dll" /INCREMENTAL:NO /NOLOGO /LIBPATH:"F:\\WORK\\netcdf_413\\netcdf-4.1.3-curl-fortran\\win32\\NET\\Release" /LIBPATH:"F:\\WORK\\netcdf_413\\bin\\x32" /LIBPATH:"F:\\WORK\\netcdf_413\\lib\\x32" /LIBPATH:"../Release" /LIBPATH:"..\\..\\..\\lib\\x32" /LIBPATH:"..\\..\\..\\bin\\x32" /DLL "Ws2_32.lib" "wsock32.lib" "advapi32.lib" "user32.lib" "hdf5_hldll.lib" "hdf5dll.lib" "zlib1.lib" "sz.lib" "libcurl.lib" "libxdr.lib" "ssleay32.lib" "libeay32.lib" "libidn.lib" "kernel32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /NODEFAULTLIB:"LIBCMT.lib" /MANIFEST:NO /ManifestFile:"Release\\netcdf.dll.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"F:\\WORK\\netcdf_413\\netcdf-4.1.3-curl-fortran\\win32\\NET\\Release\\netcdf.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /PGD:"F:\\WORK\\netcdf_413\\netcdf-4.1.3-curl-fortran\\win32\\NET\\Release\\netcdf.pgd" /TLBID:1 /DYNAMICBASE:NO /IMPLIB:"F:\\WORK\\netcdf_413\\netcdf-4.1.3-curl-fortran\\win32\\NET\\Release\\netcdf.lib" /MACHINE:X86 /ERRORREPORT:QUEUE

I have to use/NODEFAULTLIB:"LIBCMT.lib" option

And when I run the builed executable it gives an error like : the application cannot be initialized correctly. ClickOk to stop the application.

And then it shows the exception :
Exception non gre 0x7c9773be dans nctest.exe : 0xC0000142: DLL Initialization Failed

Could you explain me please, where is the problem ?

Thank you so much !

[TimP]

Is it easier to get started with all builds of both projects in /MD mode? When you mix /MD and /MT, and make a .dll, you may have to avoid linking some of those libraries directly into the .dll and instead include them in the final link. If you are taking pre-built versions of libraries from another source, you may need to read carefully any instructions which come with them.

[coolweather]

Could you explain me more in detail, please? I'm not proficien in Fortran programming.

Or perhaps, could you point me out some link to know more about different linking modes and runtime, how it functions and how to use it?

I found only this topic.

as for my case (netcdf) there is no any instruction. only this source

there is also pre-built version of netcdf dlls included in this source code (/win32/NET/Release-x32). but when I link it with my fortran code I have the same error.

the ideal solution for me to link netcdf statically to my project. but I don't know how to do it.

thank you for your help!

[Arjen_Markus]

The options /MD and /MT have as a consequence that different run-time libraries are required.
Mixing them (for instance, /MD in your DLL and /MT in your actual program) means that the
run-time libraries associated with both options must be present in the path.

So the easiest way is to make sure everything is compiled with either /MD or with /MT.

The tool dependency walker (http://www.dependencywalker.com/) may help you find out which
are missing when youtry to run the program (it does have a few limitations though).

Regards,

Arjen

[coolweather]

I've rebuilt with /MD option the both projects. The run time initialization error is still here

where could be the problem?

the pre-build version of netcdf (library in question) and its tests run correctly on my PC

when I call this lib from my program all is compiled well but there is runtime error mentioned above.

I've recompiled netcdf lib with /MD option as well as my project. the error exists, no changes.

[Arjen_Markus]

It is not very probable that these delay-load warnings are the cause.

I will try and have a look later.

Regards,

Arjen

[coolweather]

Yes, thank you!

I've read http://www.dependencywalker.com/faq.html- these dll are not the cause.

the source code can be downloaded from hereif needed.

Visual Studio solution is in\netcdf-4.1.3-curl-fortran\win32\NET\ folder

in this solution there are two projects

1. netcdf - C++ project (dll library with static linking)
2. test_prog_f90 - fortran main project that tests the fortran90 API call of this netcdf library

[mecej4]

I was able to build and run the example test_prog.f90 with IFort 12.1/IA32 using this download or prebuilt DLLs and libraries :

ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32/netcdf-4.1.1-win32-bin.zip

The command line:

ifort /O2 /MT test_prog.f90 netcdf_f90.lib netcdf.lib

Alternatively, you can use /MD and specify the linker options /nodefaultlib:LIBCMT.LIB /nodefaultlib:LIBIFCOREMT.LLIB

The file test_prog.exe in the .Zip file that you attached earlier would not run for me since it calls MSVCR90.DLL, which I do not have.

[mecej4]

>what the file 'netcdf.inc' did you use ?

I used the one in the 4.1.3 distribution that you listed in #7. I tried the one that you attached to #9, and that worked, too.

I found that the Fortran 77 library routines in the 4.1.1 distribution that I referred to in #8 use the CVF linkage, whereas the Fortran 90 routines use the native Intel Fortran linkage -- a rather strange combination. To compile your last example, I did

ifort /MT /Ot /iface:cvf nctest.f90 netcdf_f90.lib netcdf.lib

Running the resulting program created an empty foo.nc file.

[coolweather]

Dear Mecej4,
If it is not difficult for your could you send me this as Visual Studio project, please ?

Thank you very much!

[coolweather]

Dear Mecej4, one more question, if I have a main C project that is linked to netcdf and other fortran projects which also use netcdf via fortran90 api interface of netcdf, which calling convention to use in C project (intel v12 compiler too)?

there are only three options /Gd (cdec), /Gr (fastcall), and /Gz (stdcall).

for ifort compilation you used /iface:cvf call, is it the same as stdcall ?

and if I compile my main C with /Gz (stdcall), it means that all my fortran projects linked to main C I have to recompile with /iface: cvf or stdcall or stdref ? what exactly option should I choose ?

thank you for your explanations and help!

[TimP]

If you are able to use libraries which are compatible with cdecl, you should use that. This has been Microsoft's recommendation, and the default, for over a decade (for both 32- and 64-bit, ever since Microsoft began 64-bit support).
/iface:cvf diverges from stdcall in some respects where stdcall wasn't adequate to support Fortran. It was provided only to allow for linking with cvf compatible libraries. Since cvf hasn't been supported for a decade, and no longer works at all well with currently supported Windows versions, there aren't even historical reasons for using that convention with current compilers.

Although there has been recent work on implementing stdcall in mingw compilers, that variation won't give you any useful compatibility with /iface:cvf, even for 32-bit compilation. In my opinion, continued attempts to work with stdcall and /iface:cvf spread your efforts out too thin; you would be more productive spending your efforts elsewhere.

[mecej4]

I compiled the example file at the command line, which is a file that you posted, and I linked it using someone else's binary distribution of library and DLL files (links given earlier in this thread), so I have no projects to send you.

[mecej4]

If you are going to be constrained to using prebuilt binary distributions of NetCDF, you have little choice: you have to use the calling convention adopted by whoever built the libraries and DLLs in the distribution.

I believe that /iface:cvf is more appropriate than /Gz, for this reason: the binary distribution said that it was intended to be used with Intel-32 Fortran and PGI-32 Fortran. The difference between /iface:cvf and /Gz lies in how string lengths are passed. I do not know if any NetCDF routines have string arguments.

If I were a regular user of NetCDF, I would compile the libraries and DLLs from the sources myself, using the default calling conventions, for IA32 and for x64.

[coolweather]

• If I were a regular user of NetCDF, I would compile the libraries and DLLs from the sources myself, using the default calling conventions, for IA32 and for x64.

that is what I'm doing but I don't understand why this library does not want to link

• v4.1.1 gives link 2019 errors
• v4.1.3 builds, but gives run-time error

[coolweather]

some addings :

in ordre to use netcdf fortran90 API I have to compile all fortran projects with /iface:cvf option(other options give LNK 2019 error - unresolved links).

is there some more or less easy way to change call standards on __cdecl ?

thank you !

[mecej4]

You (and, in my opinion, Intel) are not in a position to make the changes desired.

The authors of NetCDF chose about a decade ago to support Powerstation Fortran (from MS), which used StdCall, and PGI Fortran continues to use the CVF linkage in its current 32-bit compiler as default. The NetCDF group releases binary distributions to match.

Subsequently, Intel Fortran became a leading compiler, and uses a different default linkage (CREF). The NetCDF people (and contributors) do not release a binary distribution compatible with /iface:cvf, and it is quite difficult, if not impossible, to build NetCDF from the source distribution using MS/Intel compilers -- there is too much reliance on Unix/Linux libraries and tools in the build procedure.

I reached this conclusion after spending some time building the latest versions of NetCDF and the prerequisites: HDF, Zlib and SZip on Linux (using Intel compilers) , Cygwin-32 (using GNU compilers) (for both of which things went smoothly, as expected) and Windows (using Intel compilers).

Several attempts on Win7 failed, but I found the reasons for the failure:

• need for library functions not available with VC, such as dirname;
• unavailable header files, typically for low-level stuff,
• insistence of .o suffix for object files in the configurescript in those parts that probe the compilers by running them on several test programs. I took care of this by editing the script, but the other problems remained.

[coolweather]

I've built netcdf 4.0.1 beta version on Intel v12 compilers with /MT & /iface:cvf options.

Now I have to adapt all my fortran projects to /MT and /iface:cvf calls.

My solution compiles but in the functions when there is string passing the application crashes.

is there some remedy to this ?

example:

[bash]! the value of file_name is
! '../management.dat                                                                                  '


CALL myRoutine(TRIM(file_name))


SUBROUTINE myRoutine(management_name)
     CHARACTER(len=150), INTENT(in)     :: management_name    ! name of management file

! here the value of management_name is
! '../management.dath|X[p                                                                          '
! and INDEX(management_name, '.dat') will crash the application

END SUBROUTINE [/bash]

(sorry it seems this error is not influenced by call convention, I verified)

PS. The NetCDF people are searching somebody who accept to recode netcdf for Windows (Visual Studio 2010 + Intel XE compilers + .NET wrap and communication to DB)

[TimP]

If you're going to ignore the requirement to specify the character string length consistently in caller and callee, you should at least set the option /gen_interfaces so as to give the compiler a chance to tell you about that and similar problems.