Problem with IFCOM (ConvertStringtoBstr)

[Paul_Curtis]

Mycode usesConvertStringtoBstr, based on some sample code supplied with CVF for interaction with Excel spreadsheets; worked perfectly in CVF, with interfacein DFCOM.

In IVF, (the interface to) this function resides inIFCOM. However, the linker flags this call as:

error LNK2019: unresolved external symbol _IFCOM_mp_CONVERTSTRINGTOBSTR@8

Is this a problem with IFCOM, or is this function to be accessed via an interface in some other module?

TIA

Paul Curtis

[Steven_L_Intel1]

It looks as if you can't use this and /iface:cvf at the same time. I think the compiler should not be changing the interface to a module procedure - I'll look into that.

[ipattielgc]

Steve is correct. I submitted this very thing as a bug to Premier Support a few months ago, and their "solution" was to say it was not meant to work with compiler option iface:cvf. Course, this is balderdash, it avoids the problem. Just create an interface for the routine (which is the correct solution), or recompile it yourself using "iface:cvf" then link your new one, and all will work.

Maybe submit a bug report as well,we can ware 'em down! Really, supporting multiple interfaces in all the libraries perfectly is very, very difficult.

If I didn't have so much code that depended on mixed char string length...

Ian

[Paul_Curtis]

Well, I did an end run around this problem by copying the relevent routines (out of Excel97a.f90 which came with CVF) into my own code, removing the "dllexport" decoration, USEing IFCOM, and everything now works. I note also that Excel97a takes about 10s to compile on CVF, and requiresmore than 5 minutes on IVF8.1.

For the record, my conversion from 8.0 to 8.1took less than 4 minutes, worked perfectly. MyCVF codemigration seems largely complete; biggest problem was figuring outthat I needed toadd the /Qsave option in IVF. Without /Qsave, the SAVE directivewithin a module or subroutine does not seem to work according to its definition, particularly in a multithreaded context.

I also found thatwhena project is imported into IVF, the dependency checker is not automatic, but apparently needs to be "trained" by manually compiling all the modules untilone hits upon the proper order to satisfy the implicit dependencies. Once this has been done, the IVF dependency checking seems to work very well, with no evident superfluous compilations; this was the part that was broken in CVF.

[ipattielgc]

Hehe, I did the same thing, I made a custom smaller version of Excel97a.f90. The last time I tried to compile the whole thing I gave up after an hour, 5 mins is a big improvement!

[Steven_L_Intel1]

We wuuld like to see an example where SAVE does not work as intended. Please submit one to Premier Support.

I generally find that a "Rebuild All" is useful in establishing the dependencies.

[Paul_Curtis]

1. IVF Help on SAVE:

In Intel Fortran, certain variables are given the SAVE attribute, or not, by default:

• The following variables are saved by default:
  
  
  • COMMON variables
  • Local variables of non-recursive subprograms
  • Data initialized by DATA statements
    
    
• The following variables are not saved by default:
  
  
  • Variables that are declared AUTOMATIC
  • Local variables that are allocatable arrays

This is exactly the way CVF worked. In IVF, however, nothing seems to be saved by default, and local variables tend to get their eggs scrambled, especially in multithreaded contexts, which problem is similar to but not the same as preserving values between sequential invocations of the same routine -- ie, values spontaneously change from one line of code to the next.

Adding the SAVE attribute sort of works, except that an error message is generated if local ALLOCATABLE arrays are present. Invoking the /Qsave compiler option solves this completely, restoring things to the reliable way that CVF worked. This is very mysterious and difficult to debug, when seemingly good, well-proven code suddenly goes bonkers. I note that another current forum query framed in terms oflogical-expression evaluation order is likely exactly this same problem, making a formerly well-behaved subscript go bad.

2. "Rebuild All", when applied to newly imported, wholly-uncompiled modules, uses some arbitrary (file-save order? alphabetical?) build order which ends the entire process when the first compile with an unsatisfieddependence fails. The IVF dependence data is apparently only deduced and retained once a module successfully compiles. Thus in my current project, 76 highly interdependent modules with heavy Win32, I had to tediously rebuild and winkle out the correct build order by hand until it all compiled, at which point IVF took over the dependency checking and now it works fine (this part never worked in CVF). What is evidentlymissing is a global pre-build pass to determine the dependencies of an entire set of modules within a project, which can then inform the actual build process.

[Steven_L_Intel1]

SAVE ought to work in IVF exactly as it did in CVF. If it doesn't, it's a bug. I'll try some examples and see.

It is true that there does not seem to be an equivalent of the CVF "Update all dependencies" menu item. I'll have to ask our expert about that.

[Paul_Curtis]

Once a set of project files has been successfully compiled, the "build" option will then follow a dependency-based build order and correctly (efficiently) do the job, so you only recompile those modules which are actually affected by a change, and the selection is automatic.

However,"Rebuild All" voids any existing dependency information, and thus requires a tedious manual rebuild from scratch. No fun at all for a large multi-module project. The lack of an"Update all Dependencies" really slows things down. I note that VS has a dependency setup option menufor multiple projects within a solution, but not for components (modules) within a project.