Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Intel Fortran Compiler Help files missing from VS2019

TonyRichards
Novice
2,823 Views

Hi,

I have returned to Fortran programming now that I can get a free Intel Fortran compiler under the Community umbrella - Thanks Intel!

I hav emany legacy DVF projects I want to refamiliarise myself with.

I have, as far as I am able to tell, installed the OneAPI base toolkit and the One API HPC, which should have installed an Intel Fortran compiler and integrated it into my copy of VS 2019 Community edition..

Two questions:

1) There is no Help for the Intel Visual Fortran Compiler under the VS2019 Help...Intel Compiler and Libraries...Intel Visual Fortran Compiler in my Visual Studio 2019 installation.

 

2) In VS2019,  I have converted a DVF project, deleted the files recommended be deleted, and cleaned the /Debug and /Release folders. I have attempted to build the debug version. All went ok escept for the messages

Error LNK2001 unresolved external symbol _WinMainCRTStartup

Error LNK1120 1 unresolved externals

Because there is no Help installed, VS cannot find the help referred to under LNK2001 and LNK1120.

I cannot find winmaincrtstartup in any of the project files.

some of my files invoke

USE DFLIB
USE DFWINTY
USE DFWIN

which I cannot find now, and I do not know whether the routes to them of their IVF equivalents have been defined properly.

 

Advicewould be greatly appreciated

regards

Anthony Richards

(73 yrs old, ex-brown belt!)

0 Kudos
1 Solution
19 Replies
TonyRichards
Novice
2,792 Views
Thanks, Steve.
Great to hear you are still above ground.
Just like old times it seems, except you remember everything
and I definitely do not.
I'll try installing the help as soon as.
The missing external is the killer ATM though.
Thanks again.
P.S. I recall certain .bat files had to be run after installing
some previous compilers. Is that no longer necessary?
0 Kudos
mecej4
Honored Contributor III
2,783 Views

The module files for DFWIN, DFWINTTY and DFLIB are provided with the OneAPI HPC installation. If they are not being found at build time, that is probably because the environment has not been set up for building Fortran projects.

OneAPI provides a batch file, setvars.bat, which is run if you launch a CMD window for OneAPI from the Windows Start menu. From within such a command window, the devenv command should launch a Visual Studio session and you can try building your project there.

0 Kudos
andrew_4619
Honored Contributor II
2,773 Views

What is the entry point of your program? It is normal for a windows app for it do be winmain. Does your program have /winapp in the compile options and /SUBSYSTEM:WINDOWS in the link options? It looks to me from the error that the project settings are not correct but it is hard to be sure, further detail would be needed. 

 

0 Kudos
TonyRichards
Novice
2,772 Views

Hi,

Thanks for replying.

I found setvars.bat in the /intel/oneAPI/ directory and ran it.

Still have the problem 'Unresolved external symbol  _WinMainCRTStartup'

I note that /Subsystem(Windows) is used as a Linker option and i believe that

WinMainCRTStartup is one expected value for the entry point of the .EXE file being constructed.

The code for ALL of my DVF Fortran Windows programs start with the following in the main program file:

 

integer*4 function WinMain( hInstance, hPrevInstance, lpszCmdLine, nCmdShow )
!DEC$ IF DEFINED(_X86_)
!DEC$ ATTRIBUTES STDCALL, ALIAS : '_WinMain@16' :: WinMain
!DEC$ ELSE
!DEC$ ATTRIBUTES STDCALL, ALIAS : 'WinMain' :: WinMain
!DEC$ ENDIF

 

Nowhere is WinMainCRTStartup mentioned. I do not see how my main program can be genering any entry point

requirement named  _WinMainCRTStartup.

Do I have to change parts of this block?

Thanks again.

0 Kudos
andrew_4619
Honored Contributor II
2,763 Views

Is this a 32 bit or a 64bit build? The Integer*4 won't be liked much for a 64 bit build, for what it's worth my Winmain template looks like this, using BIND(C) and minimal !DEC$ cludge. That should work for 32 or 64 bit.

 

function WinMain( hInstance, hPrevInstance, lpszCmdLine, nCmdShow ) bind(C, name='WinMain')
    use Ifwin
    implicit none
    !DEC$ ATTRIBUTES STDCALL :: WinMain
    integer(INT_PTR)                      :: WinMain
    integer(HANDLE), intent(in), VALUE    :: hInstance
    integer(HANDLE), intent(in), VALUE    :: hPrevInstance
    integer(LPVOID), intent(in), VALUE    :: lpszCmdLine
    integer(DWORD), intent(in), VALUE     :: nCmdShow

 

0 Kudos
TonyRichards
Novice
2,733 Views

Hi,

Thanks for your help again.

I added /ENTRY(WinMain) to the Linker..Advanced property page and the Linker failed message says that now _WinMain is the missing external!

I replaced the previous !DEC$ IF DEFINED...(_X86_) stuff with just

!DEC$ ATTRIBUTES STDCALL, ALIAS : '_WinMain' :: WinMain
!DEC$ ATTRIBUTES STDCALL, ALIAS : 'WinMain' :: WinMain

!DEC$ ATTRIBUTES STDCALL :: WinMain

In the Configuration Manager for the Debug Active Solution Configuration, the active solution platform is listed as x86, the project platform as Win32. Should this be changed? to what?

regards

Anthony

 

 

 

0 Kudos
Steve_Lionel
Honored Contributor III
2,690 Views

@TonyRichards wrote:

Hi,

Thanks for your help again.

I added /ENTRY(WinMain) to the Linker..Advanced property page and the Linker failed message says that now _WinMain is the missing external!

I replaced the previous !DEC$ IF DEFINED...(_X86_) stuff with just

!DEC$ ATTRIBUTES STDCALL, ALIAS : '_WinMain' :: WinMain
!DEC$ ATTRIBUTES STDCALL, ALIAS : 'WinMain' :: WinMain

!DEC$ ATTRIBUTES STDCALL :: WinMain

In the Configuration Manager for the Debug Active Solution Configuration, the active solution platform is listed as x86, the project platform as Win32. Should this be changed? to what?

regards

Anthony

 

 

 


You need to add DECORATE to the second choice:

!DEC$ ATTRIBUTES STDCALL, DECORATE, ALIAS:"WinMain" :: WinMain

0 Kudos
TonyRichards
Novice
2,652 Views

I have followed your suggestion and done this Steve.

The problem remains.

This is my code defining my WinMain entry to a Fortran Windows Dialog application.



Here is the code defining my WinMain...

function WinMain( hInstance, hPrevInstance, lpszCmdLine, nCmdShow )
    use Ifwin
    implicit none
    !DEC$ ATTRIBUTES STDCALL, ALIAS : "_WinMain" :: WinMain
    !DEC$ ATTRIBUTES STDCALL, DECORATE, ALIAS:"WinMain" :: WinMain
    integer(INT_PTR)                      :: WinMain
    integer(HANDLE), intent(in), VALUE    :: hInstance
    integer(HANDLE), intent(in), VALUE    :: hPrevInstance
    integer(LPVOID), intent(in), VALUE    :: lpszCmdLine
    integer(DWORD), intent(in), VALUE     :: nCmdShow

 
    use user32
    use kernel32
    use dfwinty
…..
…..

Attached is a file of screenshots showing the Linker command line used WITHOUT and WITH an ENTRY name being added to the LInker command line, accompanied by the different  Build errors that I get when trying to build the Debug configuration.

In the first case, _WinMainCRTStartup is being looked for and not found, in the second case the missing external is _WinMain.

Note the underscore! I am concerned that not all the necessary libraries are being searched during linking, or the list of externals being generated by the compilation does not list the external's name for the WinMain entry correctly, so that it does not match the external link waiting to be found in the listed linker libraries. Which sounds weird to me, as AFA I know, ALL the Fortran Windows programs have a WinMain so  named.!

0 Kudos
TonyRichards
Novice
2,651 Views

..with regard to my just previous reply, this is the part of the DVF - compiled linker that references the libraries to be searched by that linker...

# ADD BASE LINK32 version.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:windows /machine:I386
# ADD LINK32 version.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:windows /machine:I386

0 Kudos
andrew_4619
Honored Contributor II
2,728 Views

I am not saying this is your only problem but as I noted earlier Winmain is not integer*4 for a 64 bit build. Why not just try the winmain start lines I posted above then at least the interface will be correct.

 

0 Kudos
TonyRichards
Novice
2,705 Views

Hello again,

I have done what you recommend and copied your recommended specification for WinMain.

The code compiles ok, but somehow _WinMain is still not found by the linker, even though /ENTRY(WinMain) is added. THis implies that the underscore is added to the /ENTRY value.

 

Also, when I use the search for WinMain in VS studio using Find in Files searching all F90 files in the project directory (just in case there is another stray WinMain somewhere!)

it finds no matches, but if I search only the one file that I know WinMain is defined in, there is no problem finding all the occurrences.

This is perplexing.

I'll try and get a linker output listing and go  through it.

regards

Anthony Richards

0 Kudos
andrew_4619
Honored Contributor II
2,700 Views

You need /SUBSYSTEM:WINDOWS but I is not normal to have /ENTRY.  Why not post the buildog.html amd we can see all teh option that are being used and any messages. 

0 Kudos
TonyRichards
Novice
2,695 Views

I would post a build log .HTML file if one were produced, but there is no such file with HTML extension in the debug folder!

I would dearly love to have access to an example simple windows dialog project written in Fortran, that compiles, builds and runs, so I can examine it and run it using the Intel Fortran compiler installed in my in VS 2019 ide.

 

 

0 Kudos
Steve_Lionel
Honored Contributor III
2,642 Views

Drop the first ATTRIBUTES directive with the _WinMain alias. The second one is all you need.

Is this a 32-bit or 64-bit application? You don't need to define an entry point, but do need /subsystem:windows (Linker > System > Subsystem). It reads to me as if you created a console application project and then tried to shoehorn a "Windowing" application into it.

Create a new Fortran project of the type "Empty Project" and add your source files to it.

0 Kudos
TonyRichards
Novice
2,633 Views

Thankyou for your advice.

It raised a couple of questions that I have asked myself.

A) in VS2019 There appears to be several options that one must decide between when approaching the task of migrating a well-tested and debugged DVF Fortran project to a reliable IVF project with minimal difficulty:

1) File...New...Fortran Project From Existing Code, which looks straightforward.

2)File...New...Project...which opens a Ceate New Project window that offers many templates,; various languages, platforms and project types. The language and platform selections are pretty clear, and project types, except I'm not sure what 'Desktop' projects are compared to the obvious Console and Library types, for example, unless it means everything other than what's inamed in the project type lists.

I guess I'd select Fortran and windows. Although there is no place yet to select 32-bit to run on a 32-bit, 32 bit to run on 64-bit, or 64-bit to run on 32-bit, or 64-bit to run on 64-bit. Where is this done, or where is the help to decide/select?

3) File...New...Project...Project from existing Code, which offers only Visual C++, Basic or C#, which obviously I'm not interested in at the moment, except in so far as I may want to convert an existing mixed-language Fortran/C++ project at some point in the future after I have hopefully managed to achieve some useful familiarity with the new IDE of VS2019 and the migration process.

4) Project...Extract Compaq Visual Fortran Items. This I have tried, with the frustrating results (for me) that you may now be familiar with. Since It appears to bypass the other 3 routes, I do not know what project type it visualises for the converted project, although I trust that there would be enough data in the existing CVF or DVF project file, and enough intelligence in the VS or IVF converting software to decide that.

B) There is no immediate guidance available, without some insider knowledge, of how to address the question of 32-bit versus 64-bit, either in the program code or in the machine running the platform. When I open  Configuration Manager, there are defaults x86 for the 'Active solution platform' and 'Win32' for the platform. I do not know exactly what these cryptic words embody in terms of statements about what n-code is generated and what n-bit processor platform the developed application is to run on. I am running a 64-bit Intel Processor machine, which I'm sure both VS and Intel oneAPI recognise. However, neither knows where-else I intend my application to run, except one assumption is that it needs to be able to run on my machine for a start, but also neither  know what n- bit any newly added program code was originally written and developed on and targeted at (except possibly when a DVF project .dsp is available).

 

I'm sure that is enough for now. I shall go back to the drawing board, as it were, and go the long way round by adding all my .F90 files, resource, .RC,.FD and .H files to a new (empty) Fortran Windows project, with the modified WinMain code, where required, and see how it goes. Have a nice weekend.

regards

Anthony

 

P.S. a Forewarning: some time down the line I will want to convert 32-bit .HLP files that some of my applications offer.  Is all my old Help stuff likely to be useable do you think?

 

 

 

 

 

 

0 Kudos
andrew_4619
Honored Contributor II
2,638 Views

Also get rid of the link option /MACHINE:I386 

 

0 Kudos
Steve_Lionel
Honored Contributor III
2,623 Views

I would expect "Extract Compaq Visual Fortran Project Items" to be the simplest, but it may leave in options you don't want and not apply newer options you do. I generally recommend creating a new blank project of the appropriate type and adding your sources to it. You can use "New Fortran Project from Existing Code" as well. Don't use "Project from existing code" as that doesn't know about Fortran.

Even though you have a 64-bit system, it still runs 32-bit applications just fine. At present, when you create a new Intel Fortran project it defaults the configuration to 32-bit ("x86" and "Win32" both refer to this - they mean the same thing.) At least Intel Fortran now also creates a 64-bit (x64) project configuration, so if you want to do a 64-bit build, use the Solution Platforms dropdown in the top control bar (to the right of Debug/Release) to select that. Do keep in mind that if you have made any changes to project settings, the default is to apply them to the current configuration only, so you may have to repeat these.

I expect that at some point in the future Intel will default to the x64 configuration in the same way that Visual C++ already does.

Microsoft has deprecated .hlp files, but I think they still work. I haven't played with these.

0 Kudos
TonyRichards
Novice
2,360 Views

Thanks for all your assistance.

 

I have decided to draw a line under trying to continue with XFLOGM in this one program I have not yet converted using a modern Intel Compiler and an up to date  VS IDE.

 

I am going full windows API  in Fortran, since I have converted code for other windows dialog programs, so going to start trying to convert it to use the up to date Intel Classic Fortran compiler.

 

thaanks again. I will definitely be returning with more queries in due course!

regards

Anthony Richards

0 Kudos
Reply