VB Can't Find DLL

[Phares__Cliff]

I'm using IVF 11.1 and Visual Basic from Visual Studio 2005 on a Windows XP.
I use the Visual Studio IDE.

I have 2 fortran DLLs: fDLL1 and fDLL2.
fDLL2 makes use of fDLL1 - I use DLLIMPORT statements includedin aninterface.fi .
I use DLLEXPORT etc with each routine in both sets of source code.
When I link from a fortran console application, it all works fine.
All my environment variables seem to be defined correctly.

Whena VB app calls fDLL2 it cannot find it.
When I remove fDLL1 references in fDLL2 and rebuild, then the VB app sees it.

When I create a DynamicLink project in VS2005, the build makes a .lib file.
Is that the same lib file which is created if I were to create a StaticLibrary project in VS2005 and build it ?

Should Ilink fDLL2 to a fDLL1.lib ? (if that makes sense).
I can't make fDLL2 modules into a static library because VB would never see it - correct ?

If the fortran source containsDLLEXPORTs and the other cDEC$ statements,
does that interfere with the static library build ?

I don't mind making all my fortran libraries static, that works fine w/ all fortran apps.
But I don't think it would work well with VB.

I sure would appreciate any advise or references.

Thanks,
- ConfusedCliff

[DavidWhite]

Are both DLLs on the PATH?

You may want to try Dependency Walker (dependencywalker.com) on both DLL's and see what is missing? it may not be your DLL but one that your DLL calls.

David

[Cliff_Phares]

fDLL1.DLL and fDLL2.DLL are moved to the same directory in a post-build processing step.
I can call fDLL1 from the VB code - it works fine.

I ran the Dependency Walker - fDLL1 islisted as a dependent in fDLL2.DLL.
fDLL1 uses LIBIFCOREMD.DLL, MSVCR80.DLL, and KERNEL32.DLL.
fDLL2 uses fDLL1.DLL, LIBIFCOREMD.DLL, LIBMMD.DLL, MSVCR80.DLL, and KERNEL32.DLL

Thank you

[anthonyrichards]

Quoting - Cliff Phares

fDLL1.DLL and fDLL2.DLL are moved to the same directory in a post-build processing step.
I can call fDLL1 from the VB code - it works fine.

I ran the Dependency Walker - fDLL1 islisted as a dependent in fDLL2.DLL.
fDLL1 uses LIBIFCOREMD.DLL, MSVCR80.DLL, and KERNEL32.DLL.
fDLL2 uses fDLL1.DLL, LIBIFCOREMD.DLL, LIBMMD.DLL, MSVCR80.DLL, and KERNEL32.DLL

Thank you

In my limited experience with Visual Basic (almost entirely used within MS Access or Excel), you have to tell VB explicitly where to find functions that exist in external DLLs. I use statements such as

Public Declare Function ComputeMult Lib "C:Windowssystem32dll2_test.dll" (A1 As Single, A2 As Single) As Single
Public Declare Sub ComputeMultArray Lib "C:Windowssystem32dll2_test.dll" (A1 As Integer, A2 As Single, A3 As Single)

So long as VB knows where to find the DLL's, then it will 'find' thefunctions and subroutinescontained inthem. Are you using similar statements?

[IanH]

Quoting - pharesc

I have 2 fortran DLLs: fDLL1 and fDLL2.
fDLL2 makes use of fDLL1 - I use DLLIMPORT statements includedin aninterface.fi .
I use DLLEXPORT etc with each routine in both sets of source code.
When I link from a fortran console application, it all works fine.
All my environment variables seem to be defined correctly.

Whena VB app calls fDLL2 it cannot find it.
When I remove fDLL1 references in fDLL2 and rebuild, then the VB app sees it.

When I create a DynamicLink project in VS2005, the build makes a .lib file.
Is that the same lib file which is created if I were to create a StaticLibrary project in VS2005 and build it ?

Could you elaborate a bit more about how you build the DLL's? Perhaps post the build logs from the working console application build and then from the build that creates the DLL's for VB.

What's in interface.fi? Is there a reason that you cannot put the fDLL1 stuff into fortran modules and then have in fDLL2's code something like "USE stuff_from_fDLL1"? That can make this sort of stuff easier, because of automagic DLLEXPORT to DLLIMPORT manipulation and the other niceties associated with use of modules.

The lib built while building a DLL is different to the lib built while building a static library. In the DLL case the lib file is what is known as an import library. It contains information about the routines/variables that are in the companion DLL (the things that the DLL exports), but not (much) actual machine code (that's in the DLL). Applications linked against this import library will go looking for the DLL when they are loaded.

More philosophically, if VB (or any other environment that has to use dynamically linking to pick up your code) is never going to call directly into fDLL1, then I don't see the point in having it as a separate DLL. Turn it into a static library and link fDLL2 against that. fDLL2 will then contain all the code and VB calls into that.

IanH

[Cliff_Phares]

Quoting - IanH

Could you elaborate a bit more about how you build the DLL's? Perhaps post the build logs from the working console application build and then from the build that creates the DLL's for VB.

What's in interface.fi? Is there a reason that you cannot put the fDLL1 stuff into fortran modules and then have in fDLL2's code something like "USE stuff_from_fDLL1"? That can make this sort of stuff easier, because of automagic DLLEXPORT to DLLIMPORT manipulation and the other niceties associated with use of modules.

The lib built while building a DLL is different to the lib built while building a static library. In the DLL case the lib file is what is known as an import library. It contains information about the routines/variables that are in the companion DLL (the things that the DLL exports), but not (much) actual machine code (that's in the DLL). Applications linked against this import library will go looking for the DLL when they are loaded.

More philosophically, if VB (or any other environment that has to use dynamically linking to pick up your code) is never going to call directly into fDLL1, then I don't see the point in having it as a separate DLL. Turn it into a static library and link fDLL2 against that. fDLL2 will then contain all the code and VB calls into that.

IanH

Thanks IanH

I worked to build a simpler version of the problem code and it worked this time. I think there are too many versions of the DLLs floating around.

Philosophically, I agree with you. My particular VB app didn't call fDLL1, but other VB apps do.

This is the simple system I built this morning. I know that it doesn't make sense to have these two DLLs, but it will illustrate the problem.
fDL1 contains a real function AddXY(X,Y) = X + Y
fDL2 contains a real function YLine(M,B,B) = AddXY(M*B,X)

A fortran Static Library doesn't work if I include DLLEXPORT directives in the source.
A vb program can't find the entry points if I don't include DLLEXPORT directives.

I prefer to use static libraries with fortran code but am forced to use DLLs with VB.
I would like to use the same source code.
Do folks define symbols and do some pre-processing/directivelogic to add DLLEXPORTs when building DLL's ?
How do people manage their code when creating static libraries for fortran and DLL's for VB ?

Thanks for your time

[Steven_L_Intel1]

You can try this:

!DEC$ IF DEFINED (_DLL)
!DEC$ ATTRIBUTES DLLEXPORT :: name
!DEC$ END IF

_DLL is predefined if /dll or /libs:dll is set

[Cliff_Phares]

Quoting - Steve Lionel (Intel)

You can try this:

!DEC$ IF DEFINED (_DLL)
!DEC$ ATTRIBUTES DLLEXPORT :: name
!DEC$ END IF

_DLL is predefined if /dll or /libs:dll is set

Thank you - it worked just fine and will allow me to use the same source code in DynLibs as in StatLibs.
By the way, is there a means, in a post-build step, besides using DEL to execute the Build/Clean function ?

Thanks,
Cliff

[Steven_L_Intel1]

Um, if you did a Build > Clean as a post-build step, you'd wipe out everything you built. Is that really what you want?

[Cliff_Phares]

Quoting - Steve Lionel (Intel)

Um, if you did a Build > Clean as a post-build step, you'd wipe out everything you built. Is that really what you want?

Prior to Build>Clean, I copy the DLL and LIB file to the correct folders. I'm trying to keep my system a bit cleaner.

If linking to a VB app, do I need any other files than the DLL ?
If I dynamically linking to a fortran app, then I think I need the LIB and DLL files. Is that correct ?

If the VB app needs other files than the DLL, where does it seek them ?

Thanks again,
Cliff

[Steven_L_Intel1]

VB needs only the DLL. Natiive languages need the LIB. I don't know of a way to do a Clean as a post-build step. You may have to use the DEL command.