- 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
* Add "C:Program FilesIntelCompilerFortran9.1IA32Lib" to PATH
* Redistribute the libifcorert.dll along with your dll
* Link your dll with static run-time libraries (Project/Properties/Fortran/Libraries/Use run-time-library)
You should also keep /iface:CVF for calling compatibility with Excel.
A recommended dll-inspector is
Dependency Walker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jugoslav,
Thanks. I actually did a more thorough search on the forums over the weekend and came across Depency Walker (probably from another post of yours!). And when I ran it on my dll it found some needed dlls that were missing.
Those dlls were not on my harddrive so I booted up the installation disk and and "re-installed" everything, including IMSL by choosing the repair option. I believe that installed the needed dlls, which I ended up putting in the same directory as the dll just to simplify things.
So I tried Dependency Walker again and two more "not found" dlls were listed, one being LIBIFCOREMDD.DLL; similar to the one you mentioned, and something called LIBMMDD.DLL Googling LIBMMDD.DLL suggests that it has something to do with Windows file security. It's a hard one to find information about. I haven't googled the other yet. Right now I'm not sure how to acquire these. I will take a look at theMicrosoftknowledge base.
You mentioned:
"You should also keep /iface:CVF for calling compatibility with Excel."
I like to use the IDE, how does one do this if you are not using the command line? In CVF(usingVisual Studio) there were places to put switches (most of which I think were put in automaticallyand most of which I didn't understand) but I can't findwhere to do this in theIDE for IVF.
- 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
I don't know what DLLs you are finding with digits at the end of the file names.
- 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
I decided to uninstall IVF and IMSL. I re-installed IVF and let the installation wizard modify the path variable every time it wanted to. I did not re-install ISML to simplify things since I don't need it for this application.
No change. Dependency Walker still flags MSJAVA.DLL and EFSADU.DLL.
Some observations:
When I open my old CVF dll with Dependency Walker I get 11 "entries" when the list is expanded and of course nothing is flagged. When I open the IVF version I get literally hundreds; a huge dependency tree. This seems odd.
Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Guido
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was under the impression that if Dependency Walker found issues with the dll that Excel would also. That is apparantly not the case. After making several attempts to resolve the missing dlls, MSJAVA.DLL and EFSADU.DLL, I decided to just try running the Excel VBA and much to my suprise I got one of those severe errors from inside the dll. The type of error that makes Excel "disappear"; first time I've actually been happy to see one of those! Somewhere between the path issue and reinstalling (without IMSL) the problem got resolved. Now onto other ones.
I am attempting to pass a filename from the Excel VBA to the dll and the complete filename is not showing up on the Fortran side. Apparantly something has changed, of IVF is simply not as forgiving, between CVF and IVF concerning strings. I'll hack away at this one for awhile before seeking assistance.
Thanks for your help.
(I'm having trouble with spacing between paragraphs; I don't know why it's putting extra blank lines in)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you have converted the CVF project using "Extract CVF project items" context-menu function, the converter should have set CVF defaults for you. If not, go to project/properties/External procedures and set up calling convention to "CVF" and string length argument passing to "after individual string arg". That should give you CVF-compatible calling sequence (modulo some changes in functions-returning-derived-types, but that's unlikely).
- 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
Okay. Now I would like to put an executable (dll) on another machine. I'm not sure how to do this. With CVF you had to simply copy two or three FORTRAN dlls to the other machine along with the dll. I've searched this forum (not exhaustively) and could not find what dlls I'd need to copy over for an IVF executable.
From what I did see, it looks like I might have to build a release version. I tried to do this (and the final attempt had me going into configuration manager and making sure I was in the "Release" configuration) but still no luck; my VBA code can't find my "Release('d)" executable.
I also put a copy of "libifcorert.dll" in the same directory as the executable. No luck.
Dependency walker claims that my executable depends on the missing dlls "LIBIFCOREMD.DLL", "LIBMMD.DLL" and "MSVCR80.DLL".
The first two end with Ds which are not allowed to be copied to other machines and I have not done so. I have also put the directory that the execcutable is in in my Path environment variable. So something else is going on. What am I not doing right?
Mike
- 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
Steve,
Okay. Last night, after doing some more forum searching, I copied the dlls in the bin directory onto the other machine; same directory as the execuabel dll. Ialso had to copy a Visual Studio dll over as well. This got me past the "can't find dll" problem".
Then I had a problem with a string concatenating operation. This I think may have something to do with the debug and release versions compiling differently, which I had just learned about in my forum searching for the dll problem, so I wasn't completely suprised.
I was using a "character *(*)" statement which apparently is an "obscelesent fortran 95" statement. I made the strings a fixed length and used the TRIM statement in the concatenation operation to get the two strings put together correctly. I still can't get the release version to work on the other computer but the debug version of the executable dll now does.
Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The difference you are seeing is probably due to memory layout differences or perhaps optmizations that reveal a coding error that the debug version doesn't.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve etal,
The saga continues
Current situation:
The main installations of IVF 9.1 and Microsoft Studio 2005(? whatever the latest one is) are on a Dell 600m laptop with Windows XP SP 2 Home Edition. Things are working okay there.
Trying to redistribute on two other machines:
1st machine: Dell Desktop with Windows 2003 Pro SP 4. I can get the debug dll version to work (and yes I had to temporarily copy those *mdd.dll files to do this, just to see if I could get something to work) but so far not the release version; something to do with concatenating strings. (Btw, the release version seems to "find" the dlls okay on this machine.)
2nd machinge: Dell Desktop with Windows XP SP 2 Pro Edition. Can't get either debug or release version to work. Keep getting a "run time error 48" message for both verstions and it says it can't find my executable (C22DATA91.DLL). After a lot of fiddling and googling and Dependancy Walker"ing" this is what I have come up with. I copied the directory that contains my debug executable dll and supporting dlls from the "1st machine"(wherethe debugversionworks) tothe "2ndmachine". When I use Dep Walker on C22DATA91.DLLI get the following message onmachine 2 but NOT on machine 1 (orthe laptop for that matter):
Error: The Side-by-Side configuration information in "c:cell22fortran91c22data91c22data91 eleaseC22DATA91.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001)
Same thing for the release version. I do NOT have the Intel FORTRAN or Microsoft Studio 2005 installed on machines 1 or 2. I do haveCVF 6(?) installed on machine 1 though ifthat somehow might make a difference.
Sigh
Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have not seen that "Side-by-side" error before.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
I had already done both. I copied the folder that contained both the executable dll and the distributed dlls from the PC on which things worked to the 2nd PC. I had also included the directory tree to this folder in the path environment variable.
Both of these PCs are in a test cell. The one on whichI got something to work is more of a stand alone. It can see and be seen by the "corporate" (I actually work at a government installation) network but is not hardwired into it like a "borg" drone if you will. The 2nd PC is part of the "borg" network entity and has network updating software, the registry is locked out to the user etc. etc. If something doesn't work you can never tell whether or not it's because of the network stuff loaded on it. My computer at my desk is also of this type; I will try to do this on that computer when I get the chance and see if I get the same results.
Mike
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just tried it on my desktop in my office (similar setup as the 2nd pc in the test cell; assimilated into the corporate network). Same thing, "...side by side..." error.
Mike
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page