CVF Migration Problems

[mattintelnetfort]

I'm migrating from Visual Studio C++ 6.X and Compaq Visual Fortran (CVF) 6.6 and have encountered the following problems to data:

1) USEROPEN option on OPEN generates compiler error:

"Compilation aborted for d:TestProjectTest1.for (code 1)"

I get this error with my custom code (code that built fine in CVF), as well as if I try the Intel USEROPEN example "EXE1". What am I doing wrong?

2) I migrated my CVF projects (most are static libraries), but all complain about the "fast" option when compiling in Intel. If I remove the "/FAST" option from thecommand line Fortran Properties settings in studio, I no longer get the compiler warning. Should I have to do this; what is the cost?

3) I have a Visual Studio workspace from C++ 6.X with CVF projects in it. When I migrate this to Visual Studio 2003 and Intel Fortran, I must go through each CVF project and run the "Extract Compaq Fortran ..." command before compiling the fortran code with Intel - this is all fine, but when I close the migrated solution and reopen it, all the projects disallow most property settings and only show the "Command Line" settings. I have isolated to two legacy CVF projects;If I run the "Extract Compaq Fortran ..." command to fully migrate either of these two (there are about 20 total) , the next time I open the solution, I've lost the ability to view or update most property settings on any of the projects (not just the two suspicious ones). Any thoughts?

Thanks for any help!

[Steven_L_Intel1]

The USEROPEN problem is a known bug that occurs if you have /iface:cvf in effect, which the project conversion wizard added. In the project properties, select External Procedures and change the calling convention to Default and string length argument passing to "after all args".

I suggest using the options provided on the property pages to set optimization options. /fast should be accepted, but it also sets /QxP which you may not want.

I haven't seen the third problem. You may want to just recreate the projects rather than spend time trying to solve the conversion error.

[Les_Neilson]

(3) Does sound rather strange if you can change some but not all of the options. I wondered if there might be a file permission problem, but then you would not have been able to convert the projects in the first place.

For our system I converted some 360 solutions consisting of over 200 Fortran projects and over 520 C/C++ projects. Many of the solutions are mixed language. There are static libs, dlls and executables, butnot once did Iexperienceyour problem.

If the main project is C/C++ then the "command line" and "working directory" options are written to a hidden*.suo file (Visual Studio Solution User Options). Currently if the main is a Fortran project these options are written to the *.vfproj file. (This caused us a slight problem with our integration with Visual SourceSafe which I reported to Premier Support. I heard today that the issue isbeing resolved and will be put into av10compiler update.)

Sorry I can't be more helpful at the moment.

Les

[mattintelnetfort]

Uggh! Thanks for your help thus far, but I'm still hosed and in need of further help with the following:

OK so I followed the guidance on the USEROPEN issue, and now my routine compiles, but I cannot link. As I get unresolved references for any subroutines that call the subroutine that calls the OPEN command that references USEROPEN. I get XXXXX@48 unresolved reference. Further thoughts?

Also, I cannot seem to reference routines in the portability library (e.g., SLEEP, RENAME, FDATE). I tried "USE DFPORT", "USE IFPORT", and updating the project settings to specify use portability library. I continue to get FDATE@8 unresolved referenc or SLEEP@4 unresolved reference. If there something else I need to do?

Finally, how comes even if know code changes, many of the fortran projects recompile some of the source files and re-archive the libraries. I notice not all source files get recompiled, but only some?

[Steven_L_Intel1]

Do a "Rebuild" of the solution, and make sure that you are not referencing any .lib files built with CVF. As an extreme measure, delete the Debug and Release subfolders and rebuild.

Do you have EXTERNAL FDATE or the such? You shouldn't. Either USE DFPORT or USE IFPORT should work.

[mattintelnetfort]

On the USEROPEN discussion:

If I change the library project settings for the subroutine using USEROPEN to 'default' and 'after each arg', does this mean I have to change all the other libraries and DLLs to the same settings? Some of the other libraries call the subroutine with the USEROPEN usage.

Thanks for your help

[Steven_L_Intel1]

You could add directives to the routines to specify whatever calling conventions you wanted. An alternative would be to isolate the OPEN in a separate source file that is compiled specifically with the default conventions and call that from the other(s).

This bug has been fixed and the fix should show up in an update in late May.