- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Makes the default calling mechanism STDCALL rather than CREF, with arguments passed by reference and routine names upcased
- Causes string argument lengths to be passed immediately after the address of the string rather than at the end of the argument list
I suspect that the problem you're having is that when you build the Intel Fortran DLL, it is linked against run-time DLLs that you are not copying to the other system. You'd have the same problem if you went the other way.
Get the free tool Dependency Walker and run it on your DLL. Find the Intel Fortran DLLs it is using (probably libifcorert.dll, maybe more) and copy those to a directory on the target system that is in the PATH environment variable (or copy them to the Windows System folder).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
/iface:cvf, is, as far as I know, just a shortcut for /iface:stdcall + /iface:mixed_strlen_arg. Here's one explanation. It shouldn't be related with your problem though.
You can overcome the problem either by redistributing the RTL dll, or by statically linking your dll to the RTL -- change the setting for "run-time library" in both "C++" and "Fortran" categories to "Multi-threaded" or "Single-threaded" (instead of default "Single-threaded dll").
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks to you both. You are both right. By adding the Intel DLLs to the path on the non-Intel box, it works, and vice versa. And doing a static link for the DLL also works.
It is not clear (at least to me!) in the documentation that using the simple /dll switch changes the default link behavior to imply /libs:dll. If you want to get a DLL with static libraries, you have to specify both /dll and /libs:static. Using this approach, I was able to produce a DLL from either box that will run on the other. Ofcourse, the size of the DLL jumps from about 4K to about 325K, but they do work.
Thanks again,
Andy Elliott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Message Edited by tenuti on 04-20-200604:12 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This difficulty should not occur, I think, if you have used the static link approach (/libs:static switch). However, if you are using VBA (not a stand-alone exec), you need to have code in the VBA to recognize the DLLs in the local directory. I use these two lines in my VBA subs that access code in the DLL:
ChDrive ThisWorkbook.Path
ChDir ThisWorkbook.Path
Andy Elliott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There's a problem to Elliotts approach:
If the VBA code is contained in a Excel template the workbook will typically not be saved and chdrive fails. This can be solved by "on error resume next"or similar. When the workbook is not saved "File not found" is returned when user calls the DLL.
Any suggestions how to solve the problem? Ofcause to tell the user to save the workbook before proceeding but.. crappy solution.
Maybe to get the original templates directory, but how?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There's a problem to Elliotts approach:
If the VBA code is contained in a Excel template the workbook will typically not be saved and chdrive fails. This can be solved by "on error resume next" or similar. When the workbook is not saved "File not found" is returned when user calls the DLL.
Any suggestions how to solve the problem? Ofcause to tell the user to save the workbook before proceeding but.. crappy solution.
Maybe to get the original templates directory, but how?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
subroutine VERCHECK(NAME, VERSION)
!DEC$ ATTRIBUTES DLLEXPORT, STDCALL, REFERENCE :: VERCHECK
!DEC$ ATTRIBUTES ALIAS: 'vercheck' :: vercheck
CHARACTER(LEN=*), INTENT(IN) :: NAME, VERSION
And in VBA, I have
Declare Sub Vercheck Lib "VerCheck.dll" _
Alias "vercheck" (ByVal Name As String, ByVal LName As _
Long, ByVal Version As String, ByVal LVersion As Long)
Call Vercheck(Name, Len(Name), Version, Len(Version))
The DLL can be called properly from another Fortran program, but I get Error 28, stack overflow from VBA.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Message Edited by PLF on 05-26-200601:28 PM

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page