DLLIMPORT and paths

[Intel_C_Intel]

Hi!

I've inherited a DVF DLL from a colleague. This DLL uses another DVF DLL, so there's a DLLIMPORT attribute. The code looks like this:

!DEC$ATTRIBUTES DLLIMPORT :: Q:AllChenxPcratingL10

I can't get this to compile! The compiler comes back with a bunch of "unrecognized token" exceptions for the backslashes. Then it gives me a syntax error because it reads the next line as the attribute! My colleague says he's never had a problem compiling that line. Is there a switch in the project settings that I'm missing?

Thanks in advance,
Robin Olson

[Steven_L_Intel1]

The code is wrong - the DLLIMPORT directive should name the routine (as called by Fortran), not the DLL file (which is found using the normal Windows path rules.)

For example, you might have:

!DEC$ ATTRIBUTES DLLIMPORT :: MY_SUB

...

CALL MY_SUB

This DLL should then link against the export library (.lib) of the DLL being called.

Steve

[Intel_C_Intel]

Hi Steve,

I've had the same suspicions about the code - in the past, I've always given the DLL reference in DLLIMPORT, not a file and path name. He says he's doing it because the application which uses these DLLs is written in Excel VBA and the user's Excel settings control the default path.

Does that matter with DLLIMPORT? I thought the calling DLL would look for the called DLL according to the Windows path settings. However, we're getting "Error 53: File not found" when we try to call our DLL from Excel. All of the dependents for both DLLs are in place and the VBA DECLARE statements include the DLL paths.

Also, if the code is wrong, do you have any idea why his copy compiled and mine won't?

Thanks for the help!
Robin

[Steven_L_Intel1]

You can get the file-not-found error if DFORRT.DLL is not installed or isn't on the path.

I seriously doubt his code compiled as-is, unless it was by a very old compiler that didn't accept !DEC$ATTRIBUTES (instead of !DEC$ ATTRIBUTES) and just ignored the directive.

Steve

[Intel_C_Intel]

Hi Steve,

DFORRT is installed in the system directory, so that's not the problem. And he's running the same copy of DVF that I am. I guess I'll have to stand over his shoulder and watch his compile! (I work remotely, so I haven't had the opportunity to do that.)

Thanks for all the help!
Robin Olson

[Steven_L_Intel1]

Remember also that L10.DLL needs to be located by Windows default rules. Either in the PATH or in the same folder as EXCEL.EXE. The folder your DLL that calls L10 is in doesn't matter.

Steve

[Intel_C_Intel]

Hi Steve,

I'll look into the L10 location. Thanks!

Robin Olson