DLL, dependecies, ad maybe more...

[bertazza]

Dear IVF users.

I'm trapped in DLL Hell. I wrote a VBA code running on top of ArcMap (ESRI), which calls several DLLs built in IVF10/VS2005. On some systems, everything works all right, but on others, one DLL generates the dreaded VBA error "file not found" (while other DLLs dont).

Now:

All the DLLs where built using exactly the same project options, all of them in release mode.

All the dependencies appear to be satisfied (libifcoremd.dll, libifportmd.dll, libmmd.dll, msvcm80.dll, msvcp80.dll, msvcr80.dll, Microsoft.VC80.CRT.manifest are there).
Checking dependencies with DependencyWalker shows no problems. The only difference I can see is that the working DLL depends on LIBIFCOREMD.DLL and LIBMMD.DLL, while the non-working DLL depends on LIBIFCOREMD.DLL and LIBIFPORTMD.DLL.

All the DLLs have the manifest embedded, and manifests are identical.

The machines where the problem occurs run WinXP SP2 (32 bit). I tried the whole thing on a clean Win XP SP2 machine (with no other software installed): no problems.

I checked the versions of all the VC DLLs, and they look consistent.

I then used FileMon to try to sort out the problem. I so discovered that the working DLL, after being loaded, rummages a bit inside the WinSxs folders, and then loads LIBIFCOREMD.DLL, LIBMMD.DLL, LIBFPORT.DLL and the VC DLLs.
The non-working DLL instead, after being loaded, rummages a bit inside the WinSxs folders, and then loads the NTDLL.DLL, not even trying to look for the Fortran redistributable DLLs it should load. It doesnt find them because it doesnt even look for them!

Lastly, I try building the DLLs with IVF9 on VS2003: no luck, same problem on same machines.

What did I do wrong? Why one of my DLLs works all right everywhere and the other fails on some systems?

Thanks for your help
Alberto

[Steven_L_Intel1]

I can't explain the VS2003-build problems. Have you tried opening the DLLs with Dependency Walker to see what it says?

For the VS2005 issues, try installing the VS2005 redistributables installer.

[bertazza]

Steve,

thank you for your help!

I did as you advised, with no luck. Even installing the VS2005 redist package, the error persists for one and only one DLL.

As I mentioned in my first post, Dependency Walker shows no Errors, only the usual Warnings.

Any further suggestion?

Thanks again
Alberto

[Steven_L_Intel1]

My usual advice in such cases is to write a small Fortran test program that calls the DLL routine and try running that to see if you get a meaningful error message. The Fortran code doesn't have to actually execute the call.

[bertazza]

Steve.

If I get it right: I write a simple executable fortran app that calls the problematic DLL, and I should get some useful error msg.

But what do you mean when you say "the Fotran code doesn't have to actually execute the call?".

Thanks again
Alberto

[Steven_L_Intel1]

What you are testing is the ability to load the EXE and DLL, not make the calls. You'll either get an error starting the EXE or not. You can put a STOP statement before the call to the DLL routine if desired.

[bertazza]

Steve,

sorry about bothering you with dumb questions. Be patient...

I wrote this simple code that calls my dll (GridToDxf.dll):
-----------------------------------

program test1

use kernel32
implicit none

INTEGER :: hLib, iSt
character(256) :: fileCommand

INTERFACE
SUBROUTINE sub(fileCommand)
character(256) :: fileCommand
END SUBROUTINE
END INTERFACE
POINTER(lpfnfunc,sub)

fileCommand = 'command_GridToDXF.txt'

hLib = LoadLibrary("gridtodxf.dll"C)
lpfnfunc = GetProcAddress(hLib,"RAS_TO_DXF"C)
pause

CALL sub(fileCommand)
iSt = FreeLibrary(hLib)

end program test1

----------------------------
Now, this program works, providing the GridToDXF.dll file and its dependencies are there. But if those files are not there, I get an access violation error only when I actually call the DLL, not when I start di EXE as you said it should happen.

I'm clearly doing something wrong...

Thanks a lot
Alberto

[Steven_L_Intel1]

This isn't what I meant for you to do - it won't provide any more information. You get the access violation because you do not check for an error from LoadLibrary or GetProcAddress.

What I was suggesting was that you write a program such as this:

program test
external RAS_TO_DXP
!DEC$ ATTRIBUTES ALIAS:"RAS_TO_DXP" :: RAS_TO_DXP
accept *, i
if (i == 999999) call RAS_TO_DXP
end

Compile this and link it against the .LIB created when you built the DLL. Now run it. Enter 0 at the prompt if you get that far.

[bertazza]

All right Steve.

I finally managed to build that little program on your template. I put it in the same folder where the faulty DLL was. The program worked, but that same DLL gave the error "Error 53 - file not found" when called from inside VBA.

Since other DLLs did not present the problem, I started suspecting that the problem could be in the Fortran code. Therefore, I created a new empty DLL, and added to it chunks of code from the faulty DLL. I indeed found that the problem "Error 53 - file not found" in VBA was due to some offending code.

In one of 2 faulty DLLs, the thing seems to be related to some write statements. I couldn't get more precise, due to the code complexity. But in the other DLL I managed to spot out the only line of code responsible for the problem:

Class = aint(0.9999 + 10**(rmodulo - aint(rmodulo))) * 10**aint(rmodulo)

This line is located inside a plain subroutine. Class is an global integer, rmodulo is a local real. I can provide the remaining code if needed.

By commenting this single line of code, the problem "file not found" disappeared! I've check and re-checked.

As I said, this only happens on some machines (all of them running Win XP SP2). Could it be a problem of VBA? Or maybe, it's something related to implicit functions (like aint)?

Thanks

Alberto

[Steven_L_Intel1]

It sounds to me as if VBA is unable to locate the libifcoremd.dll or libifcorert.dll, depending on how you built your DLL. Removing statements that cause calls to the RTL mean that the RTL DLL is not needed.

Remember that VBA has to look in the "standard locations" for the run-time DLLs - it does not know to look in the same folder as your DLL or in places you may have set for PATH on a command prompt.

Check the system PATH environment variable (Right click on My Computer, Properties, Advanced, Environment Variables) and make sure that the system PATH variable includes a folder where the IVF run-time DLLs are placed.

[bertazza]

Steve,

I've already tried adding the DLL's folder in the PATH system variable, it doesn't help.

The things that are puzzling me are:
- why is that very line in the DLL code causing the error? There are several other lines calling the same intrinsic functions in the code.
- why only 2 out of several DLLs cause the problem? They should at least behave consistently. They've been compiled with the same parameters, same compiler, same VS version.

I'm baffled and befuddled
Alberto

[Steven_L_Intel1]

Can't say, really, without (perhaps) sitting on your system and investigating. Usually I find that Dependency Walker is a good analysis tool for such problems. I would suggest using that on each of your DLLs and compare the results.

[bertazza]

Is there any chance of avoiding the problem by linking the libraries statically ?

I will anyway check the DLLs more thoroughly with Dependency Walker, and see if I figure something out.

Thanks for your help
Alberto

[Steven_L_Intel1]

Yes - as long as no Fortran code is calling your DLL that will work. In the Fortran > Libraries property page, change the Use Run-Time Library to "Multithreaded".

[bertazza]

Steve,

just so you know: strangely enough, linking the libraries statically didn't help either :(

I'll keep trying, and see if I find something out.

Alberto