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

no print output

Jeff_D_5
Beginner
1,153 Views

I have a problem that probably has a simple answer. When I install the sample NQueens Fortran program, it works as I would expect. However, when I try to create a simple program that prints "Hello world," I get no output. Specifically, I fire up Intel Parallel Studio XE 2016 for Windows, choose File->New->Project and select Console Application and pick Main Program Code. The code template that automatically shows up just prints "hello world." I then pick Build, open PowerShell, go to the Debug folder, and run the program Console1.exe. Nothing happens. If instead I use the Command window, then instead I get the error message "The program can't start because libifcoremdd.dll is missing from your computer."

I have looked through the configuration and compared it to the NQueens configuration, and I don't see any obvious difference.

Thanks for any help.

 

 

 

0 Kudos
1 Solution
IanH
Honored Contributor II
1,153 Views

Jeff D. wrote:

Ian, thanks for your interest. I will make these modifications to my path and give it a try. However, I am slightly skeptical that this is the problem, because the sample codes that come with the Intel compiler work properly.

The samples that you have tried are likely all built with static linking, which was the default project configuration up until some years ago.  Consequently they don't need to find the DLL forms of the runtime library at runtime, and consequently they don't care about your path.

If there is an example that uses OpenMP then I I suspect you will find that it fails to run, as the OpenMP runtime library is only available as a DLL these days.

To show you what you should expect...

I have only just moved to Windows 10, and I see that they have dramatically improved the PATH editor.  To access it press Windows-Break (or find System in Control Panel), then Advanced System Settings, click Environment Variables, under the System variables select "Path" and click Edit.  If you are using an earlier version of windows, then you will basically just see a long line of text (hence the recommendation to use a separate text editor to sort things out).

path-edit.png

I have installed the 2017 beta, and its installation has created the first two entries that are additional copies of the runtime that somewhat duplicate the "normal" runtime directories that start with the %INTEL_DEV_REDIST%... environment variable.  We'll see if the beta installation cleans that up correctly in a month or two when 2017 proper comes out.  (In this case the C:\Windows and C:\Windows\system32 directories are duplicates created with the upgrade to Windows 10 - the canonical form of those appear further down with references to the %systemroot% environment variable.)

From within powershell, $env:path shows...

PS U:\> $env:path
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.0.072\windows\mpi\intel64\bin;C:\Program Files (x86)\In
telSWTools\compilers_and_libraries_2017.0.048\windows\mpi\intel64\bin;C:\Program Files (x86)\Common Files\Intel\Shared L
ibraries\redist\intel64_win\mpirt;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\mpirt;C:\Pr
ogram Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;C:\Program Files (x86)\Common Files\In
tel\Shared Libraries\redist\ia32_win\compiler;C:\ProgramData\Oracle\Java\javapath;C:\Perl64\site\bin;C:\Perl64\bin;C:\Pr
ogram Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live
;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x

The %INTEL_DEV_REDIST% environment variables have been expanded.  If you are not seeing that, then things are broken.

Note that we have been talking about the system PATH above.  When you start any program the system expands environment variables in the stored path and then appends the user path.  From within a program like powershell or a command prompt, further changes to the path can then be made.  Even if the system path expansion fails, those later changes to path can still happen successfully.  Try running your program from within the relevant command prompt provided by the compiler, which makes such changes to PATH, and see if it then works.

 

View solution in original post

0 Kudos
9 Replies
IanH
Honored Contributor II
1,153 Views

Are the runtime libraries for the compiler on your PATH?

0 Kudos
Jeff_D_5
Beginner
1,153 Views

According to Visual Studio XE 2016, the library dependencies are linked.

0 Kudos
IanH
Honored Contributor II
1,153 Views

If your application has been linked against the DLL variant of the Fortran runtime libraries (which is the default, and would appear to be the case for your project), then in the environment that you are running your program, the directory with those runtime libraries needs to be in your PATH.  Depending on options selected during installation this may have been done for you, or you may have to set it up yourself.

From within powershell, if you enter $env:path do you see a directory or directories starting "C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\xxxx" or similar?  (From within the console window, just use the PATH command.)

If not, then you need to set those paths up.  The compiler installation provides shortcuts for various command prompts in its start menu program group that will have those paths set correctly.

0 Kudos
Jeff_D_5
Beginner
1,153 Views

Gosh, I think so. The first four entries of my $env:path are
%INTEL_DEV_REDIST%redist\intel64_win\mpirt;%INTEL_DEV_REDIST%redist\ia32_win\mpirt;%INTEL_DEV_REDIST%redist\intel64_win\compiler;%INTEL_DEV_REDIST%redist\ia32_win\compiler

When I compare the Build Logs for one of the sample programs, vs my short program, I do see a slight difference, but I don't see a way to modify in the Build Configuration manager. For example, when I Build the gap_samples program (supplied with the compiler), the ifort line in the log has a "/libs:static" entry (w/o the quotes). When I Build my program, the same line has a "/libs:dll" entry instead. But I don't see where to set this in the Build Configuration.

Again, thanks for your help.
Jeff

0 Kudos
IanH
Honored Contributor II
1,153 Views

Assuming you have rebooted since installing the compiler....  if your "operating" path contains unexpanded environment variables (like %INTEL_DEV_REDIST%), then you have run into a Windows problem where those variables cannot be expanded because the resulting path string will be too long.  Lots of things (though all perhaps relatively minor) stop working properly when that happens.

This situation is not an uncommon one.  Intel's choice of directory layout for its runtime libraries doesn't help, but often it is just the straw that broke the camels back.

(By operating path I mean the path as viewed by $end:path or the PATH command, where you are supposed to see the result of the combination and expansion of the user and system components of the path.   If you are separately viewing the user and system path components through the control panel applet or similar (which version of Windows are you on?), then those two separate components are shown in their unexpanded form.)

Regardless of how you build and link your programs, if you can I suggest you review the user and system (particularly) components of your path and try and remove directories that are not really required.   In the first instance look for duplicate entries (including entries that will be duplicates once any embedded environment variable references are expanded) - sometimes installers get confused and double up on something that is already there.  You may also have entries for programs that are no longer installed.  Too many programs also have a vastly inflated view of their importance and will have put their directories in the system path even though that is not necessary to effectively use them - those entries require a little more judgement on your part.  Before editing the system path save its unexpanded contents to a text file or similar so that you can always recover its original form in case you chop too far (it is probably easier to do all the editing in a text editor like notepad anyway, and then copy and paste the result rather than use the single line entry field that the control panel applet or registry editor provides).  Make sure you leave the windows system directories in the path.  Consult Dr Google for more detailed instructions on how to access the system path settings, I see an intel support variant of the instructions here.

(If you haven't rebooted since installing the compiler, then do that and check your path again before any or all of the above!)

By default these days, new projects are set to build using the DLL form of the runtime libraries (and hence when you run the result of compiling those programs you need to have a directory with the runtime DLL's accessible on the PATH).  You can change the project to build using the static form of the runtime libraries in the properties for the project under Fortran > Libraries, Runtime Library - and choose an option that does not have "DLL" in its description (this is how you set the /libs:static command line option).  Despite this option, use of some compiler language features (OpenMP) will still require the DLL form of the runtime libraries.

0 Kudos
Jeff_D_5
Beginner
1,153 Views

Ian, thanks for your interest. I will make these modifications to my path and give it a try. However, I am slightly skeptical that this is the problem, because the sample codes that come with the Intel compiler work properly.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,153 Views

To rephrase IanH

What you need to obtain is the actual expansion of the environment variables as observed by the program(s) running in your command shell (PowerShell). You do not want to look at the script that is used to specify the environment variables (not at first).

Now then as IanH stated, should you see something like: %INTEL_DEV_REDIST%redist..., meaning you see the %variable%... then %variable% was not expanded, and therefore you have an error in your script that specifies the environment variables (now you look at your script to see why). Start with why (in this hypothetical) your script did not define INTEL_DEV_REDIST=C:\Program Files.... correct path here...

Jim Dempsey

0 Kudos
IanH
Honored Contributor II
1,154 Views

Jeff D. wrote:

Ian, thanks for your interest. I will make these modifications to my path and give it a try. However, I am slightly skeptical that this is the problem, because the sample codes that come with the Intel compiler work properly.

The samples that you have tried are likely all built with static linking, which was the default project configuration up until some years ago.  Consequently they don't need to find the DLL forms of the runtime library at runtime, and consequently they don't care about your path.

If there is an example that uses OpenMP then I I suspect you will find that it fails to run, as the OpenMP runtime library is only available as a DLL these days.

To show you what you should expect...

I have only just moved to Windows 10, and I see that they have dramatically improved the PATH editor.  To access it press Windows-Break (or find System in Control Panel), then Advanced System Settings, click Environment Variables, under the System variables select "Path" and click Edit.  If you are using an earlier version of windows, then you will basically just see a long line of text (hence the recommendation to use a separate text editor to sort things out).

path-edit.png

I have installed the 2017 beta, and its installation has created the first two entries that are additional copies of the runtime that somewhat duplicate the "normal" runtime directories that start with the %INTEL_DEV_REDIST%... environment variable.  We'll see if the beta installation cleans that up correctly in a month or two when 2017 proper comes out.  (In this case the C:\Windows and C:\Windows\system32 directories are duplicates created with the upgrade to Windows 10 - the canonical form of those appear further down with references to the %systemroot% environment variable.)

From within powershell, $env:path shows...

PS U:\> $env:path
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.0.072\windows\mpi\intel64\bin;C:\Program Files (x86)\In
telSWTools\compilers_and_libraries_2017.0.048\windows\mpi\intel64\bin;C:\Program Files (x86)\Common Files\Intel\Shared L
ibraries\redist\intel64_win\mpirt;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\mpirt;C:\Pr
ogram Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;C:\Program Files (x86)\Common Files\In
tel\Shared Libraries\redist\ia32_win\compiler;C:\ProgramData\Oracle\Java\javapath;C:\Perl64\site\bin;C:\Perl64\bin;C:\Pr
ogram Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live
;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x

The %INTEL_DEV_REDIST% environment variables have been expanded.  If you are not seeing that, then things are broken.

Note that we have been talking about the system PATH above.  When you start any program the system expands environment variables in the stored path and then appends the user path.  From within a program like powershell or a command prompt, further changes to the path can then be made.  Even if the system path expansion fails, those later changes to path can still happen successfully.  Try running your program from within the relevant command prompt provided by the compiler, which makes such changes to PATH, and see if it then works.

 

0 Kudos
Jeff_D_5
Beginner
1,153 Views

Thank you Ian. I've got it working. Would not have been able to without your help.

​Jeff

0 Kudos
Reply