A problem with a dll file

[teclis77]

Hi,
I have a problem when I link a dll file; i.e. I am recompiling (I come from CVF 6.6 to ICV 9.0) and testing all my libraries, both static and dynamic.
When I test one of these DLL, compare an error message:

"Cannot find Fortran libifcore DLL in process address pace"

I hit enter and then another error message appears:

"Application not correctly inizialized (0x0000142). Hit OK to close the application"

The program consist in a main file with only the declaration of all the variables and definition of the inpuit variables; then the call of the dll and, at least, a series of write for the output variables.

Moreover my command line is

ifort cond1.f /link condizioni_iniziali.lib

How I can resolve my problem?

I want to say, also, that another dll tests were good.

Best Regards

Teclis

[Steven_L_Intel1]

I have no idea what would put out that particular message, if you have transcribed in correctly.

Please make sure that your PATH environment variable includes "C:Program FilesIntelCompilerFortran9.0IA32Bin".

[teclis77]

The path is absolutely correct (I have already red a previuos post with similar problem)

Teclis

[Steven_L_Intel1]

Is that the exact text of the error message, or did you change it?

[teclis77]

This is the exact error message:

"Cannot find Fortran libifcore DLL in process address pace"

and this is a possible translation from Italian to English:

"Application not correctly inizialized (0x0000142). Hit OK to close the application"

Teclis

[Steven_L_Intel1]

That first message must be coming from your application. I am certain it is not coming from any Intel code. Perhaps there is some code that tries to do a LoadLibrary of libifcore.dll? If it is looking for that specific name, then you want to be sure you use the "single-threaded DLL" setting for Libraries..Use Run-time Library.

[teclis77]

My library is a simple subrotinue with some Mathematicalfunctions, like dsin() or dsqrt().

The only difference with my other libreries is that I use "use ifport" in order to generate a random number ( drand() ).

Teclis

[Steven_L_Intel1]

At this point I am going to suggest that you submit a support request to Intel Premier Support and attach a ZIP file of the folders containing your DLL and test project, including the already-built DLL and EXE. I can't figure out what is putting out that message, especially one with a misspelling. (not that we haven't had misspellings in error messages, but I can't find any message in our libraries even close to what you report.)

Once we see the project we may be able to help you more.

[teclis77]

Thank you Steve,

I have opened a support tequest.

Best Regards

Teclis

[Steven_L_Intel1]

Thank you for submitting the files and especially the screen shots. The actual text of the first error was "Can not find Fortran libifcore DLL in process address space". I was confused by not having the correct text.

This is a strange one. You will get this when you have linked against the DLL form of the Fortran run-time libraries, have called a routine in the Portability library, but have not caused the main Fortran DLL library libifcore to load. In your case, your DLL used the portability library but did no I/O or anything else that used libifcore, and your EXE was linked against the static Fortran libraries. It would seem that the initialization for libifportmd.dll tries to find libifcoremd (or mdd) in the address space - exactly why, I don't know - and gives this error if it does not find it.

The easy solution is to link the EXE against the Fortran DLL libraries too so that libifcoremd.dll will be there. I have asked the developers to look at this problem.

[Jugoslav_Dujic]

The easy solution is to link the EXE against the Fortran DLL libraries too so that libifcoremd.dll will be there.

Or, even easier, link the dll with static run-time libraries :-).

I'm not a particular fan of dll RTLs, especially since Intel did not release yet an easy-to-use "redistributable pack" as was the case with CVF. Necessity to use dll RTLs is pretty rare (when the dll and the .exe share the unit numbers or do mutual (de)allocation). I understand that was the rationale to select dll RTL as the default project settings for dlls, but often it poses more problems than it solves (and executable size is barely an issue these days).

[teclis77]

Thank You Steve,
now it seems that the executable file works well.

But I don't understand one thing: is better if I add the switch /libs:dll every time that I link a dll file?

Best Regards

Teclis

[Steven_L_Intel1]

You get /libs:dll automatically when you link a DLL. The problem is that you need to say /libs:dll when you link the EXE that is linked to the DLL.

[teclis77]

You want to say that:

ifort myexec.f /libs:dll mydll.lib

instead of

ifort myexec.f /link mydll.lib

Teclis

[Steven_L_Intel1]

Yes. In your case, the /link is not necessary. That switch tells ifort that everything after it should be given to the linker only. But in the case of a .lib, ifort knows what to do with it.

In most cases, I disagree with Jugoslav regarding DLL libraries. I have seen too many customer complaints that were caused by inconsistent libraries. Yes, if you distribute your code you have to distribute the DLLs too, but it's worse to have duplicate libraries in your application.

If you know exactly what you are doing and what your application needs, then you can get away with static linking of DLLs. In particular, if you know that no Fortran code will call your DLL, it is ok to link it statically.

Message Edited by Steve_Lionel on 02-15-2006 11:16 AM

[teclis77]

Steve, Thank you very much for your attention

Teclis