Cannot compile fortran program using ifort command-line environment or visual studio

[El_Noshokaty__Said]

Hi,

On Win 10, where I have Intel parallel studio XE 2020 integrated with MS visual studio community 2019, I'm trying to compile two fortran programs; one for .exe and another for .dll. The one for .exe has succeeded (.exe created) using the ifort command-line:

ifort /O3 /nologo /assume:buffered_io /Qinit:zero /Qinit:arrays /Qparallel /integer_size:64 /real_size:64 /double_size:64 /fpconstant /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:ldio_spacing /fpscomp:logicals /fpscomp:general /fpscomp:libs /object:"c:\sos\\" /threads /o "c:\sos\sosvoyagerprogllah1.exe" "c:\sos\lib\kernel32.lib" "c:\sos\lib\imagehlp.lib" "c:\sos\lib\msmpi.lib" "c:\sos\lib\msmpifmc.lib" "c:\sos\lib\uuid.lib" "c:\sos\lib\ifmodintr.lib" "c:\sos\lib\ifwin.lib" "c:\sos\lib\ifconsol.lib" "c:\sos\lib\libifcoremt.lib" "c:\sos\lib\libifport.lib" "c:\sos\lib\libiomp5md.lib" "c:\sos\lib\libmmt.lib" "c:\sos\lib\libirc.lib" "c:\sos\lib\svml_dispmt.lib" "c:\sos\lib\libmatmul.lib" "c:\sos\lib\libcpmt.lib" "c:\sos\sosvoyagerprogllah1.f90"

and failed in the visual studio giving the message "LINK : fatal error LNK1561: entry point must be defined". The program starts with the statement "PROGRAM".

As for the program for .dll, it fails the ifort command -line:

ifort /O3 /nologo /assume:buffered_io /Qinit:zero /Qinit:arrays /Qparallel /integer_size:64 /real_size:64 /double_size:64 /fpconstant /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:ldio_spacing /fpscomp:logicals /fpscomp:general /fpscomp:libs /object:"c:\sos\\" /libs:dll /threads /o "c:\sos\sosvoyagerprogllah.dll" "c:\sos\lib\kernel32.lib" "c:\sos\lib\imagehlp.lib" "c:\sos\lib\msmpi.lib" "c:\sos\lib\msmpifmc.lib" "c:\sos\lib\uuid.lib" "c:\sos\lib\ifmodintr.lib" "c:\sos\lib\ifwin.lib" "c:\sos\lib\ifconsol.lib" "c:\sos\lib\libifcoremt.lib" "c:\sos\lib\libifport.lib" "c:\sos\lib\libiomp5md.lib" "c:\sos\lib\libmmt.lib" "c:\sos\lib\libirc.lib" "c:\sos\lib\svml_dispmt.lib" "c:\sos\lib\libmatmul.lib" "c:\sos\lib\libcpmt.lib" "c:\sos\sosvoyagerprogllah.f90" /DLL

giving the message "Error 7001: error in creating the compiled module file." The program starts with the statement "MODULE". And failed the visual studio by doing nothing (no .dll created), giving the message " Rebuild All: 1 succeeded, 0 failed, 0 skipped"

Said 

[Steve_Lionel]

For the EXE in Visual Studio, would you please ZIP the buildlog.htm (in the Debug or Release) folder after a rebuild and attach the ZIP to a reply here?

You're doing a lot of things I would not recommend, including, it would appear, your own copies of the Intel run-time libraries. Why are you doing that? You're also using a lot of compiler options you may not need (the various /fpscomp options.)

I'd also like to see the buildlog.htm from the DLL build.

[El_Noshokaty__Said]

Hi Steve,

Please find attached the required build-log files. If I omit the lib files, ifort will start giving the error message "Cannot open the file x.lib", where x is the name of the lib file it requires, so I decided to collect them all and write them to the command line. The /fpscomp options were added because the programs were first time compiled by MS PowerStation in the late 90's and I do not want to change the code written since then.   

Said

[Steve_Lionel]

You certainly weren't building 64-bit applications with PowerStation. Be that as it may...

For the EXE project, try this. Right click on the project and select Properties. Select Linker > System.  Set SubSystem to Console. Click OK and do a rebuild.

The build log for the DLL project shows nothing happening at all - no compiles, no links. Please attach the .vfproj file for that project.

[El_Noshokaty__Said]

Hi Steve,

Please find attached the build log of the .exe project after setting SubSystem to Console and the .vfproj file for the .dll project. Why "Source1", source and obj, were created this time for the .exe project?

[andrew_4619]

That proj file does not include reference to any source file.

[El_Noshokaty__Said]

Hi Andrew,

Unlike the .exe project, Visual Studio is unable to compile the .dll project, although In each project, I simply open its .f90 file and ask for building the project. Strange!

I doubt the Intel / Visual Studio integration. Please, let us focus on the ifort command-line environment. I succeeded to compile the .exe program and failed the .dll one. Please refer to the ifort arguments and the error message displayed in my first message. Disability to compile the .dll program in the 64bit environment puts me in a deadlock position since I left the 32bit environment with no return.

Said

[Steve_Lionel]

The source1.obj is because your source file is named source1.f90.

Indeed, the DLL project file has no source files in the project.

[El_Noshokaty__Said]

Hi Steve,

In each project, I simply open its .f90 source file and ask for building the project. It is strange that the Visual Studio is satisfied with what I did and hence does not ask for a source name and build his own under the name "Source1".

I doubt the Intel / Visual Studio integration. Please, let us focus on the ifort command-line environment. I succeeded to compile the .exe program and failed the .dll. Please refer to the .dll ifort arguments and the error message displayed in my first message. Disability to compile the .dll program in the 64bit environment puts me in a deadlock position since I left the 32bit environment with no return.

Said

[Steve_Lionel]

I have some advice for VS, but will leave that for later.

The error you get from the command line indicates that the compiler tried but failed to create a new .mod file when compiling the module source. What happens if you simply do:

ifort -c c:\sos\sosvoyagerprogllah1.f90

Also, what is your current directory when you are doing these builds? Can you show me the full output from the console window, starting from when you first open it through the compile attempt?

[El_Noshokaty__Said]

Hi Stive, 

The above image is the command prompt when directory is changed to ifort directory; once with my .dll ifort command line and the other with yours.

Said

[mecej4]

Finally, you have posted information that pinpoints the problem.

You are running the compiler when the current directory is the compiler …\bin\intel64 directory. In a typical installation, the compiler directories are write-protected for non-administrator users, precisely to protect the installation from the kind of havoc such as we see here.

Before attempting any compilation, change to a working directory -- create one if you wish -- in a location where you have write permission.

Unless you are troubleshooting system problems, you should never have any of the system and software installation directories as the working directory.

[Steve_Lionel]

I suspected that might be the case, which is why I asked.

Unfortunately, the shortcuts that get installed have a non-writable directory set as their "current directory". I've griped about this before to the install developers, but nothing changed. What I do is drag one of these shortcuts to my desktop and change the start directory to one of my own choosing. I also replace the explicit compiler version path with %IFORT_COMPILER20%  - for example:

C:\Windows\System32\cmd.exe /E:ON /V:ON /K ""%IFORT_COMPILER20%bin\ipsxe-comp-vars.bat" intel64 vs2019"

which will use the latest installed update.

[El_Noshokaty__Said]

Hi Steve,

The reason behind the error message shown in the command prompt is that an object directory has to be specified in the ifort command line. Even though, the error message I posted earlier for the .dll program will then be displayed. The reason behind the latter error message is that a module directory has to be specified in the ifort command line too. So, I added the arguments: /module: "c:\sos\\" for module directory and some missing .dll libraries to my ifort command line and all is now being set (/o "c:\sos\\" for the object directory is already there).

Now, my problem is to have the Visual Studio do what ifort command line has did both for the .dll and the .exe projects. This might help in debugging the project code. You kindly said you have some advices in applying Visual Studio.

Said

[mecej4]

What you can do in Visual Studio is to create a new project in a writeable directory before you do anything else such as adding files or typing in Fortran code.

[El_Noshokaty__Said]

Hi,

The directory is writable, but I think I'm missing something here. For the .dll project, the Visual Studio cannot see the .f90 file I want to compile and its output says "Rebuild All: 1 succeeded, 0 failed, 0 skipped" without the compilation and linking taking place. As for the . exe project, the Visual Studio displays the error massage I posted in my first message here. 

Said

[Steve_Lionel]

You need to add the source file to the project. In years past, it was possible to open a source file and Visual Studio would create a project for you if you tried to compile it, but no longer.

There is "File > New > Fortran project from existing code" that is a handy shortcut to create a new project, but I never use this - I just create the project and add the sources to it.

[El_Noshokaty__Said]

Hi Steve,

Please let me know what do you mean by adding a file to a project? Do you mean opening a .f90 file while a project is already open? If this what you mean, I open the .dll .f90 file while the .dll project is open then I rebuild. The build output showed nothing as you have noticed. I need also your advice regarding the error of the .exe project as I demonstrated earlier.

Said

[andrew_4619]

Opening a file does not make it part of a project. Open the solution explorer view. You can then by right click at projects to the solution and add files to s project.

[El_Noshokaty__Said]

Hi Andrew,

I did what you said for the .dll project and all is now set.

Thank you.

Said

[Steve_Lionel]

We already took care of the EXE project issue you raised with the correction of the Subsystem property. (That property is normally preset when you create a console application project.) Of course, you now have an issue of calls to MPI routines when, it would seem, you have not told VS to link to an MPI library.