Migrating (ancient) Dec Fortran to Windows - passing structures as subroutine arguments

[Daft_Pict]

Greetings,

I have to ressurect some of my 15 year old VMS Fortran code to run on my Windows system and have run into a problem that I haven't been able to figure out from the documentation or searching on-line.

Here is an example of a compilation error I get

Error 1 Error: The type of the actual argument differs from the type of the dummy argument. [OBJ] \Visual Studio 2008\Projects\Flib\Astrom\POLYSOL.FOR 87

The record structure is defined in the main program and the subroutine using the same include file (see code snippet). I'd appreciate any suggestions to resolve this - I passed record structures between subroutines A LOT! Thanks in advance. - Brian

>>>>snippet of code

include 'astroref.inc'

record /astroref/ obj

call poly_model(model,obj,no_terms,x_plate_terms,y_plate_terms,x_plate_desc,y_plate_desc)

<<<>>>>

subroutine poly_model(model,obj,no_terms,x_plate_terms,y_plate_terms,x_plate_desc,y_plate_desc)

include 'astroref.inc'
record /astroref/ obj

<<<<<<<

[Steven_L_Intel1]

When building in Visual Studio, a new feature called "generated interface checking" is on by default. Unfortunately, this can't deal with the programming practice you are using here, which is fine in DEC Fortran 77. It would really prefer that the declaration of /astroref/ be in a module so that the declarations are "the same".

The simplest solution for you is to turn off generated interface checking. Right click on the project properties, select Fortran > Diagnostics. Change the entries for "Generate interface blocks" and "Checjk routine interfaces" to No.

If you wanted to try another approach, and if the include line immediately follows the subroutine/function/program statement, you could create a module file such as:

module astroref_def

structure /astroref/
...

end structure
end module astroref_def

Add this source to your project. Then replace the contents of astroref.inc with:

use astroref_def

You may run into other issues doing this, so I don't recommend it unless you're feeling adventurous. Perhaps over time you'll migrate to using modules and derived types rather than structures and include files.

[Daft_Pict]

Hhmmm - I seem to have a problem with project->properties. I get a "Class not Registered" error when I try to access them.

Is this a known installation problem? I've got IVF 10.1.025 installed with VS2008+SP1

[Steven_L_Intel1]

Some users have this problem. Try this.

Download repairvs08integration.zip and unpack it into a folder of your choice. Close Visual Studio and run the EXE that was unpacked. If it displays any error messages, please post the text here. Otherwise, restart VS08 and see if you can get at the properties. Let me know what happens.

[Daft_Pict]

Hi Steve - I still have the same problem with the unregistered class. Looking at the command window I see that there was an error in the repair. BTW - I do have admin privs on this system. - Brian

Visual Studio 2008 installed at C:Program FilesMicrosoft Visual Studio 9.0
Successfully unregistered VFHieEditor.dll
Successfully unregistered VFAVwin.dll
Successfully unregistered VFFortSvc.dll
Successfully unregistered VFProjConvert.dll
Successfully unregistered VFProj.dll
Successfully unregistered VFToolOpt.dll
Successfully registered VFToolOpt.dll
Error while registering VFProj.dll: Access is denied.

Press any key to exit program

[Steven_L_Intel1]

Ok, try this.

Open a command prompt window (Start > Run > CMD) and set default (cd) to the folder containing the unpacked Repairvs08integration.exe. Do this:

SET PATH=
SET LIB=
SET INCLUDE=
repairvs08integration.exe

Let me know what happens.

[Daft_Pict]

C:Data FilesDownloadsIntel VisFortran>repairvs08integration.exe
Visual Studio 2008 installed at C:Program FilesMicrosoft Visual Studio 9.0
Successfully unregistered VFHieEditor.dll
Successfully unregistered VFAVwin.dll
Successfully unregistered VFFortSvc.dll
Error while unregistering VFProjConvert.dll:
Error accessing the OLE registry.

Successfully unregistered VFProj.dll
Successfully unregistered VFToolOpt.dll
Successfully registered VFToolOpt.dll
Error while registering VFProj.dll: Access is denied.

Press any key to exit program

[Steven_L_Intel1]

That "error accessing OLE registry" error I expect and can be ignored.

Is this Vista? If so, please start the command prompt with "run as administrator" (right click on a command prompt shortcut and select Start as Administrator) and try this again.

[Daft_Pict]

Quoting - Steve Lionel (Intel)

That "error accessing OLE registry" error I expect and can be ignored.

Is this Vista? If so, please start the command prompt with "run as administrator" (right click on a command prompt shortcut and select Start as Administrator) and try this again.

Windows XP Pro and I have admin privs on this system

[Steven_L_Intel1]

Quoting - daftpict

Windows XP Pro and I have admin privs on this system

On Vista, having admin privs is not sufficient... But on XP it should. I have seen on some users' systems where they somehow got the registry into a state where parts of the registry were protected against write even by the administrator. I wonder if you have some background program that is interfering with the registry access. I could imagine some "malware protection software" doing this. If you have antivirus or similiar software, try disabling it temporarily. As a "big hammer" approach, you could reboot into Safe Mode and try doing the repair that way.

If this doesn't help I'm going to suggest submitting a request for help to Intel Premier Support - reference this thread if you do.

[Daft_Pict]

Steve - still unable to repair the VS2008 integration, even in safe mode. I've run into registry permission issues on this system before (most notably trying to install XP SP3 despite trying all the suggestions on the MS knowledgebase). I'll take another look there to see if there is anything new and try again. Thanks for your help....I can always start work on converting to the module use as you suggest. -Brian

[bredsj]

Quoting - Steve Lionel (Intel)

When building in Visual Studio, a new feature called "generated interface checking" is on by default. Unfortunately, this can't deal with the programming practice you are using here, which is fine in DEC Fortran 77. It would really prefer that the declaration of /astroref/ be in a module so that the declarations are "the same".

The simplest solution for you is to turn off generated interface checking. Right click on the project properties, select Fortran > Diagnostics. Change the entries for "Generate interface blocks" and "Checjk routine interfaces" to No.

If you wanted to try another approach, and if the include line immediately follows the subroutine/function/program statement, you could create a module file such as:

module astroref_def

structure /astroref/
...

end structure
end module astroref_def

Add this source to your project. Then replace the contents of astroref.inc with:

use astroref_def

You may run into other issues doing this, so I don't recommend it unless you're feeling adventurous. Perhaps over time you'll migrate to using modules and derived types rather than structures and include files.

Hi Steve

I have experienced a similar problem and figured the compiler settings myself. However, I have anothe problem; we work as a group and some parts of the program are stable and therefore we do not include the source code, just the .OBJ files of these stable parts. Every member of the group then work on new developments in his own domain.

The problem is that atlinking time some subroutines in OBJ files are not "seen". A typical message is:

Error1 error LNK2019: unresolved external symbol _RESEVP@184 referenced in function _MAIN__3k-1.obj

The subroutine RESEVP is in one of the OBJ files.

The code copiled successfully with CVF 6.6

I also see that a lot of code is automatically generated by the compiler of individual subroutines with _mod.f90 added to the routine name, i.e. a subroutine sd03 will exist then a new file sd03_mod.f90 is create at compile time.

I use Visual Studio 2005

I hope you, or anybody else,can help

Regards

[Steven_L_Intel1]

The call to RESEVP is being done with the STDCALL call mechanism, which CVF used by default. Intel Fortran uses the C mechanism by default, though if you convert a CVF project it sets the defaults to match CVF. I suspect there is a mismatch here.

A more serious problem, possibly, is if you are mixing Intel-compiled code with CVF-compiled code. This will not work and will cause lots of strange errors.

[bredsj]

Quoting - Steve Lionel (Intel)

The call to RESEVP is being done with the STDCALL call mechanism, which CVF used by default. Intel Fortran uses the C mechanism by default, though if you convert a CVF project it sets the defaults to match CVF. I suspect there is a mismatch here.

A more serious problem, possibly, is if you are mixing Intel-compiled code with CVF-compiled code. This will not work and will cause lots of strange errors.

Hi Steve

Thanks for the very prompt reply! It is appreciated.

I need to give you further background:

We have successfully recompiled ALL the old CVF code in the project with IVF. The next step was to:

1. transfer the .FOR code necessary to do my work; plus

2. the .OBJ of the code that I do not need (and can't get access to), to my PC

It is when I compile the code (.FOR and .OBJ) on my PC that i have the compiler error.

I have now set:

1. Project/Properties/External Procedures/Append underscore to YES

2. Project/Properties/Language/Source file format to USE FIXED FORMAT

These compiler settings got rid of the error message mentioned. However, now I get a compiler message that certain arrays are not dimensioned although they are: see the following:

real(8)

and then the code

, DIMENSION(*) ::RESID,etc.... if (ideqns.ne.0) then

resid(ideqns)=0.0d0

dpresc(IPNODS)=dpresc(IPNODS)-dispt(ideqns)

endif

generates the error message:

Error1 Error: This name has not been declared as an array or a function. [resid]C:Documents and Settingssteph_bMy DocumentsCAPACapa_SD3k-6.for58

[Steven_L_Intel1]

I cannot tell what the problem is from an excerpt or paraphrase of the actual code. If you want to attach the source, do this:

1. Click on Add Files

2. If you have not previously created a file folder here, fill in a new folder name and click Create Folder

3. Click on the name of the folder you just created

4. Click the Browse button to browse for the file, click Upload

5. Click on the name of the file you uploaded

6. Optional: edit the Title field

7. Click Add as Attachment

I am very surprised that you would need to change the properties you did, unless you also had those set in CVF.

[bredsj]

Quoting - Steve Lionel (Intel)

I cannot tell what the problem is from an excerpt or paraphrase of the actual code. If you want to attach the source, do this:

1. Click on Add Files

2. If you have not previously created a file folder here, fill in a new folder name and click Create Folder

3. Click on the name of the folder you just created

4. Click the Browse button to browse for the file, click Upload

5. Click on the name of the file you uploaded

6. Optional: edit the Title field

7. Click Add as Attachment

I am very surprised that you would need to change the properties you did, unless you also had those set in CVF.

Steve,

Once again, thanks for your helpfullness (if there is such a word).

I'll need permission to upload any source code. I'll discuss with the University and then upload.

I have checked once again; the old CVF code compiles successfully even with the Project/Properties/Fortran/External Procedures/Calling Convention set DEFAULT. The problem only arises when the source code to which I am not supposed to have access is removed and only the .OBJ files are left.

[bredsj]

Quoting - Steve Lionel (Intel)

I cannot tell what the problem is from an excerpt or paraphrase of the actual code. If you want to attach the source, do this:

1. Click on Add Files

2. If you have not previously created a file folder here, fill in a new folder name and click Create Folder

3. Click on the name of the folder you just created

4. Click the Browse button to browse for the file, click Upload

5. Click on the name of the file you uploaded

6. Optional: edit the Title field

7. Click Add as Attachment

I am very surprised that you would need to change the properties you did, unless you also had those set in CVF.

Hi Steve

I have attached 3 files:

The idea is to remove uniran.for and norran.for from the project (it is maintained by one person as an example) and only the main program, in this case rndcapa.f90 plus the .obj (norran.obj and uniran.obj) is made available to a user, who is then free to work on the main calling program, but he can't change the source related to the .obj files.

The problem that we have is that as soon as the .for files are removed the .obj files also disappear. If we copy the .obj files into the project folder a unresolved external symbol linker error is obtained.

I also see that the compiler creates _mod.f90 files. What is the reason for this?

Unfrtunately I couldn't upload the real problem project as the University refused permiossion to do so.

Your help is appreciated.

[Steven_L_Intel1]

Would you please also attach the .obj that causes the problem? Also, the buildlog.htm showing the failed link (in the Debug or Release folder).

[bredsj]

Quoting - Steve Lionel (Intel)

Would you please also attach the .obj that causes the problem? Also, the buildlog.htm showing the failed link (in the Debug or Release folder).

The requested files are attached.

Thanks

[Steven_L_Intel1]

Ok, I think I understand now.

You need to place these.,obj files somewhere other than in the project's "intermediate files" folder - that is Debug or Release. Have some sort of "shared objects" folder and add the .obj files to your project from that. The problem is that when you do a full build, all .obj files in the intermediate folder are deleted.

You could also insert them into a static library (which I consider more convenient.)

[bredsj]

Quoting - Steve Lionel (Intel)

Ok, I think I understand now.

You need to place these.,obj files somewhere other than in the project's "intermediate files" folder - that is Debug or Release. Have some sort of "shared objects" folder and add the .obj files to your project from that. The problem is that when you do a full build, all .obj files in the intermediate folder are deleted.

You could also insert them into a static library (which I consider more convenient.)

Thanks Steve.

I have already tried the "shared objects" route without success. Will try again to ensure that I didn't made a mistake.

I have considered the static library, but need to convince my colleugues. You know how a committe works, it design a giraffe.

Please read your 30 yaer blog, I left a message.

Thanks again.