ifort with NAG under 64-bit Windows

ifort with NAG under 64-bit Windows

Hello,

I am trying to migrate with my research code from Linux HPC cluster to 64-bit Windows (changed job recently and got a new PC).

The code is a set of Matlab and Fortran subroutines, which also call stand-alone NAG Fortran library. It all worked well in the old configuration with pgf90 compiler and Mark21 NAG library under Linux.

Now I have Mark23 NAG library and Intel 64 Visual Studio, of which I use 'ifort' in command line.

In my Makefile, the compilation lines are as follows:

LIBDIR = 'C:/Program Files/NAG/FL23/flw6i23dcl/bin/' LIBNAME = FLW6I23DC_nag.dll

OBJS1 = myprog.f ukf.f OBJS2 = contour.f cdens_subr.f potfit_subr.f

myprog: $(OBJS1)

$(FC) $(OBJS1) $(LIBDIR)$(LIBNAME)

 When I run the package (via Matlab envelope code), I get the following error message:

------------------------------------

ifort myprog.f ukf.f 'C:/Program Files/NAG/FL23/flw6i23dcl/bin/'FLW6I23DC_nag.dll

Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.0.089 Build 20120731

Copyright (C) 1985-2012 Intel Corporation.  All rights reserved.

ifort: command line warning #10161: unrecognized source type 'C:/Program Files/NAG/FL23/flw6i23dcl/bin/FLW6I23DC_nag.dll'; object file assumed

ipo: warning #11010: file format not recognized for C:/Program Files/NAG/FL23/flw6i23dcl/bin/FLW6I23DC_nag.dll

link: unknown option -- s

Try `link --help' for more information.

Makefile:15: recipe for target `myprog' failed

make: *** [myprog] Error 1

---------------------

I also tried static library from the same Mark23, and it did not work either. Not to mention that I tried 'nagfor' compiler before that - I managed to obtain an executable, but it crashed at call saying about division by zero (which did not happen with 'pgf90').

I would be very grateful if you advised how to resolve the compilation issue with 'ifort'.

Thank you

Valerie Livina

27 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Valerie,

Unlike on Linux where you link to .so files directly, Windows requires that you link to the "import library" that is produced when a DLL is linked. This has a .lib file type so it may look like a static library, but typically the size is much smaller.

In general, mixing object code from different Fortran compilers doesn't work as there are often naming conflicts for the libraries. Using a DLL should work. What goes wrong when you link to the .lib that goes with the DLL?

Retired 12/31/2016

Quote:

link: unknown option -- s

Try `link --help' for more information.

These messages indicate that you have Cygwin (or MINGW or something similar) installed, and the Intel Fortran compiler is finding the Cygwin "link.exe" (which does symbolic links) instead of the MS linker, which has the same name. You have to fix your PATH, or do the equivalent in the IDE, so that the MS linker is found before the Cygwin utility.

> In general, mixing object code from different Fortran compilers doesn't work as there are often naming conflicts for the libraries. Using a DLL should work. What goes wrong when you link to the .lib that goes with the DLL?

Then I have the same problem as I mentioned in my initial post. The reply below, by mesej4, mentions cygwin - indeed, I use cygwin to run the package, to imitate the linux environment under which the code was built. Is it possible to do this with ifort under Windows, or do I have to rebuild the code completely?

> These messages indicate that you have Cygwin (or MINGW or something similar) installed, and the Intel Fortran compiler is finding the Cygwin "link.exe" (which does symbolic links) instead of the MS linker, which has the same name. You have to fix your PATH, or do the equivalent in the IDE, so that the MS linker is found before the Cygwin utility.

You are right, I do use cygwin to be able to use the same Makefiles etc. Would you please advise how can I make the MS linker work (as you said, be found before the cygwin)?

Thank you

Valerie

Valerie,

It is perfectly fine to use Cygwin or some such package to emulate a Linux/Unix command line environment, but when the names of commonly used tools (such as LINK.exe) may clash you have to set the environment up properly.

Perhaps the simplest solution for you is to rename the Cygwin tool link.exe to something else and, if you do use it (probably not), to remember the new name and to change scripts that use this tool.

Another way is to modify Cygwin.bat (the Cygwin startup script) so that it does not modify PATH, and to append the Cygwin "bin" directory to PATH after opening the Intel Compiler command window (this is the approach that I am most comfortable with).

A third way is to use the /Qlocation option of the compiler, either in the compiler invocation line or in the compiler configuration file(s) (with default names ifort.cfg and icl.cfg). Please read about these options in the Intel Fortran User Guide under Using Configuration Files.

If your environment is already modified to include the Cygwin bin directory in PATH, you may need to modify it, using the System->Advanced->Environment control panel.

Hello,

Thank you very much for your advice. When I renamed cygwin's 'link.exe' (into 'link_cygwin.exe') and ran my code, I got error message:

-------------------------

ifort myprog.f ukf.f 'C:/Program Files/NAG/FL23/flw6i23dcl/bin/'FLW6I23DC_nag.dll -o myprogIntel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.0.089 Build 20120731

Copyright (C) 1985-2012 Intel Corporation.  All rights reserved.

ifort: command line warning #10161: unrecognized source type 'C:/Program Files/NAG/FL23/flw6i23dcl/bin/FLW6I23DC_nag.dll'; object file assumed

ipo: warning #11010: file format not recognized for C:/Program Files/NAG/FL23/flw6i23dcl/bin/FLW6I23DC_nag.dll

ifort: error #10037: could not find 'link'

Makefile:14: recipe for target `myprog' failed

make: *** [myprog] Error 127

ans =

     2

---------------------

I understand the Cygwin terminal lacks some settings that the command line of the Visual studio Command prompt has, to set up linking properly. I had a look at 'vcvarsall.bat' in the Visual Studio, and attempted to use the commands of the addressed 'vcvars32.bat' in the 'cygwin.bat'. I also changed for another NAG library, .lib instead of .dll. Now I get the following linking message with my code:

---------

ifort myprog.f ukf.f 'C:/Program Files/NAG/FL23/flw6i23dcl/lib/'FLW6I23DC_nag.lib -o contourprog

Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.0.089 Build 20120731

Copyright (C) 1985-2012 Intel Corporation.  All rights reserved.

ifort: error #10037: could not find 'link'

Makefile:20: recipe for target `contourprog' failed

make: *** [contourprog] Error 127

ans =

     2

-------

> Another way is to modify Cygwin.bat (the Cygwin startup script) so that it does not modify PATH, and to append the Cygwin "bin" directory to PATH after opening the Intel Compiler command window (this is the approach that I am most comfortable with).

Do you mean that I have to call the Intel Compiler Command Prompt and run cygwin from inside instead of running Cygwin first? Right now I start with cygwin (where, as I hope, I modified the startup bat-file suitably for ifort) and run Matlab from there, with recompilations via Makefile. As I understand from the message above, ifort linking is still missing. How can I configure this in cygwin?

Thank you

Valerie

Valerie,

It is not easy to give you specific instructions since we do not know how your environment is set up, why you use Cygwin and what part of Cygwin you need. Therefore, here is a suggestion to break the logjam.

1. Create a small test program in Fortran, open the IFort command window, and compile+link that program. If everything works, proceed to the next step.If not, you need to get this part working before trying anything else. Note that Cygwin plays no part in this step, unless %PATH% has already been modified by your Cygwin installation.

2. Change to the directory containing your major application and Issue the command nmake instead of make. If that goes through and builds the application, you don't need Cygwin for this work at all.

3. If nmake did not work well in Step 2, you need to use GNU make. In the same IFort command window as above, add the Cygwin bin directory to PATH. If Cygwin is in c:\cygwin, do

     C:> Path %path%;c:\cygwin\bin

so that the Cygwin path is added at the end of the previous path. Note that you are not starting Cygwin's own command shell. You are simply enabling the Cygwin tools (such as GNU make) to be used as needed.

Valerie, to add to what mecej4 says, you need to properly establish the Intel compiler environment. Normally this is done through an invocation of the compilervars.bat script found in the compiler's BIN folder - it takes an argument of either ia32 or intel64 to set the target platform. I don't know how you'd do this from Cygwin.

Retired 12/31/2016

Hello,

> Create a small test program in Fortran, open the IFort command window, and compile+link that program. If everything works, proceed to the next step.If not, you need to get this part working before trying anything else. Note that Cygwin plays no part in this step, unless %PATH% has already been modified by your Cygwin installation.

I attempted to run a line command in the Visual Studio Command Prompt, just combining all options from Makefile together:

ifort myprog.f ukf.f -l"C:\Program Files\NAG\FL23\flw6i23dcl\lib\FLW6U23DC_nag.lib"

I got the following error message:

---

ifort: command line warning #10006: ignoring unknown option '/lC:\Program Files\...\FLW6I23DC_nag.lib"

Microsoft (R) Incremental Linker Version 10.00.30319.01

-out:myprog.exe -subsystem:console myprog.obj ukf.obj LINK : fatal error LNK1104: cannot open file 'ifconsol.lib'

---

It means that the linker does not work properly and the NAG library is not found where it is.

I checked other threads in the forum and found the following discussion:

http://software.intel.com/en-us/forums/topic/302907

But I have different version of VS and I use the Command Prompt (so I assume I have to modify some bat-files instead of setting options insider the VS?)

Thank you

Valerie

 

 

Dear Steve,

> Valerie, to add to what mecej4 says, you need to properly establish the Intel compiler environment. Normally this is done through an invocation of the compilervars.bat script found in the compiler's BIN folder - it takes an argument of either ia32 or intel64 to set the target platform.

Yes, I tried to find 'compilervars.bat' in the \VC\bin subfolder (where 'vcvars32.bat' is). It does not exist in the whole Studio installation. Was it renamed in the recent versions of VS?

Thank you

Valerie

This is an Intel file - you need to look in C:\Program Files (x86)\Intel\Composer XE 2013\bin

Retired 12/31/2016

The Intel compiler start up batch files are not in the VC directory, but in the compiler's own directory; this depends on where the compiler was installed. On my system, for example, I see (I had to replace backslashes, which the forum software swallows up, by forward slashes)

 Directory of c:/Program Files (x86)/Intel/Composer XE 2013/bin
10/09/2012  09:45 PM             3,700 compilervars.bat
10/17/2012  02:26 PM            11,052 compilervars_arch.bat
10/09/2012  09:45 PM             3,700 iclvars.bat
10/09/2012  09:45 PM             3,700 ifortvars.bat
10/09/2012  09:45 PM               857 ipsxe-comp-vars.bat
10/09/2012  09:45 PM             1,350 vsshell2008vars_arch.bat
10/09/2012  09:45 PM             1,394 vsshell2010vars_arch.bat
10/09/2012  09:45 PM             1,393 vsshell2012vars_arch.bat

Dear Steve,

I see that the Command Promt startup option is "vcvarsall.bat" x86

As I understand it, this is the name of the bat-file in the new version? How can I modify it to make the compiler work with 'ifconsole.lib', please?

Thank you

Valerie

Dear Steve and macej4,

Thank you for your messages.

I just found the bat.file, and in the Studio Command Prompt I typed the following:

compilervars.bat intel64 vs2010shell

I got the error message:

------

Intel(R) Composer X 2013 (package 089)

The specified configuration type is missing. The tools for the configuration might not be installed.

-----

Was it an incorrect command or do I have to add something in the path?

Thank you

Valerie

Can you try this without Cygwin? Use the command prompt shortcut under Intel Parallel Studio XE 2013. Start that, CD to a writable folder and try building a "hello world" program.

Retired 12/31/2016

Dear Steve,

> Can you try this without Cygwin? Use the command prompt shortcut under Intel Parallel Studio XE 2013. Start that, CD to a writable folder and try building a "hello world" program.

Yes, I am trying this without Cygwin. I just discovered that in my installation of Visual Studio I have two shortcuts for command prompt. One is called "Visual Studio Command Prompt 2010", executing startup command

""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86

The second one is "Intel 64 Visual Studio 2010 mode", executing startup command

""C:\Program Files (x86)\Intel\Composer XE 2013\bin\ipsxe-comp-vars.bat" intel64 vs2010"

When I start the second one (on startup, without any command typed), it gives the same message "The specified configuration type is missing. The tools for the configuration might not be installed.

So, I start the first one which sets up correctly. As you suggested, I created a 'hello world' code. When I type

ifort -c code.f

it compiles it and creates obj-file.

When I attempt to

link code.obj

or

ifort code.f

I get the same message

LINK: fatal erroe LNK1104: cannot open file 'ifconsol.lib'

As I understand it, there may be something wrong with LIB environmental variable? How can I set it correctly for the use of ifort in the Command Prompt?

Thank you

Valerie

 

 

Valerie,

Please do not use the Visual Studio command prompt shortcuts for Fortran work.  Use one of the shortcuts under Start > All Programs > Intel Parallel Studio XE 2013 > Command Prompt > Parallel Studio XE with Intel Compiler XE 13.0

However, the second command you typed should have worked.

Please do this - in Visual Studio, select Help > About. Click "Copy Info" then paste the result into a reply here.

Retired 12/31/2016

Dear Steve,

> Please do not use the Visual Studio command prompt shortcuts for Fortran work.  Use one of the shortcuts under Start > All Programs > Intel Parallel Studio XE 2013 > Command Prompt > Parallel Studio XE with Intel Compiler XE 13.0

Thank you very much for this hint. In the path you suggested I found two shortcuts

1) IA-32 Visual Studio 2010 mode which executes startup command

"C:\Program Files (x86)\Intel\Composer XE 2013\bin\ipsxe-comp-vars.bat" ia32 vs2010"

2) Intel 64 Visual Studio 2010 mode which attempts to execute startup command

"C:\Program Files (x86)\Intel\Composer XE 2013\bin\ipsxe-comp-vars.bat" intel64 vs2010"

but this Command Prompt starts with error message: "The specified configuration type is missing. The Tools for the configuration might  not be installed.

So, the first Command Prompt starts normally and does compile and links the 'hello world' code, generating exe-file which works as expected.

Now as I know that IA-32 Command Prompt can compile, I attempt to compile my code in the command line (without Makefile) to see if I use the right options for 'ifort' with NAG library:

ifort myprog.f ukf.f -L"C:/Program Files/NAG/FL23/flw6i23dcl/bin/'FLW6I23DC_nag.dll"

I get error messages:

------

ifort: command line warning #10006: ignoring unknown option '/LC:\Program Files\...\FLW6I23DC_nag.lib'

ukf.obj: error LNK2019: unresolved external symbol _F07FDF referenced in function _UKF

myprog.exe: fatal error LNK1120: 1 unresolved externals

-----

Is this is because I try to use 64-bit library in the environment set for 32-bit or do I have to use special compiler/linker options for NAG?

> Please do this - in Visual Studio, select Help > About. Click "Copy Info" then paste the result into a reply here.

Microsoft Visual Studio 2010 Version 10.0.30319.1 RTMRel Microsoft .NET Framework Version 4.0.30319 RTMRel

Installed Version: IDE Standard

Microsoft Visual Web Developer 2010

Intel(R) Visual Fortran     Package ID: w_fcompxe_2013.0.089 Intel(R) Visual Fortran Composer XE 2013 Integration for Microsoft Visual Studio* 2010, 13.0.3588.2010, Copyright (C) 2002-2012 Intel Corporation

Yours sincerely

Valerie

You cannot link 32-bit objects (which your Intel IA-32 compiler produces) with the 64-bit NAG library. You should either install the Intel 64-bit compiler, or obtain the 32-bit NAG FL library to go with the 32-bit Fortran compiler.

Dear mecej4,

> You cannot link 32-bit objects (which your Intel IA-32 compiler produces) with the 64-bit NAG library. You should either install the Intel 64-bit compiler, or obtain the 32-bit NAG FL library to go with the 32-bit Fortran compiler.

Is it possible to configure the Command Prompt so that it would run with 64-bit compiler? Or can you tell from the description of my Visual Studio that I have only 32-bit Fortan compiler?

Thank you

Valerie

 

You are trying to use Linux syntax for the command line and are still naming a DLL on the ifort line - this won't work. If you have the import .lib corresponding to this DLL, simply name it on the ifort line as if it were a source file.  However, you can't mix 32-bit and 64-bit code, so if the NAG library you are linking to is 64-bit, you need to do a 64-bit build of your application.

I see you are using the included Visual Studio Shell, which is fine. Have you by any chance installed any other Visual Studio products on this system, such as an "Express Edition" of Visual C++?

Retired 12/31/2016

Dear Steve,

> You are trying to use Linux syntax for the command line and are still naming a DLL on the ifort line - this won't work. If you have the import .lib corresponding to this DLL, simply name it on the ifort line as if it were a source file.  However, you can't mix 32-bit and 64-bit code, so if the NAG library you are linking to is 64-bit, you need to do a 64-bit build of your application.

I installed 32-bit Mark22 NAG library and using IA-32 Visual Studio Command Prompt I compiled the code with NAG library by the following command

ifort myprog.f ukf.f "C:\Program Files (x86)\NAG\FL22\flw3222dcl\lib\FLW3222DC_nag.lib

It produces an exe-file, and I am certain that it works, because when I run the exe-file outside the matlab-package with input parameters in the command line, it generates an output series as it should. Now I have to adjust the Makefile to be able to run it using 'nmake' (so that I would not need to use Cygwin and just run Matlab from the IA-32 Visual Studio Command Prompt).

My Makefile is as follows:

---------

OBJS1=myprog.f ukf.f OBJS2=contour.f cdens_subr.f potfit_subr.f

LIBNAME=FLW3222DC_nag.lib LIBDIR='C:\Program Files (x86)\NAG\FL22\flw3222dcl\lib\'

myprog.exe: $(OBJS1)

ifort $(OBJS1) $(LIBDIR)$(LIBNAME)

contourprog.exe: $(OBJS2)

ifort $(OBJS2) $(LIBDIR)$(LIBNAME) /exe:contourprog.exe

clean: del *.exe *.obj

-----------

When it is called, it produces the following error message:

 makefile(10) : fatal error U1034: syntax error : separator missing

I understand that nmake is different from make, but as I am reading various online manuals and examples, my simple makefile seems correct to me - would you please advise what is wrong with syntax there?

> I see you are using the included Visual Studio Shell, which is fine. Have you by any chance installed any other Visual Studio products on this system, such as an "Express Edition" of Visual C++?

I found installed Microsoft Windows SDK, which also has its own Command Prompt, 64-bit configured and calling startup script

"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd"

However, since the 32-bit NAG library is working with my code now, I am happy with it and just want to adjust the Makefile to be able to use 'nmake', so I am looking forward to your advice regarding that.

Thank you

Valerie

 

I'm not an nmake expert - perhaps someone else can comment.

Retired 12/31/2016

Your makefile is defective (one reason may be that when you paste its contents into a post, tabs, which are rather important in makefiles, may get converted to spaces; line-breaks, which are also important to preserve in makefiles, can get mangled as well).

I have attached a fixed up makefile (remove the .txt suffix before using).

Attachments: 

AttachmentSize
Downloadtext/plain val.mak.txt364 bytes

Dear mecej4,

Thank you very much for looking into this.

> Your makefile is defective (one reason may be that when you paste its contents into a post, tabs, which are rather important in makefiles, may get converted to spaces; line-breaks, which are also important to preserve in makefiles, can get mangled as well).

Yes, you are right: this is how the content of the file went into the webform by copy&paste, without linebreaks

> I have attached a fixed up makefile (remove the .txt suffix before using).

I just saved it on my computer (without any editing) and attempted to run my codes with this Makefile - I got the following error messages:

-------

LINK : fatal error LNK1104: cannot open file ''C:\Program.obj'

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Intel\Composer XE 2013\bin\ia32\ifort.EXE"' : return code '0x450'

ifort: command line warning #10161: unrecognized source type ''C:\Program'; object file assumed

ifort: command line warning #10161: unrecognized source type 'Files'; object file assumed

ipo: error #11018: Cannot open 'C:\Program ipo: error #11018: Cannot open Files

ipo: error #11018: Cannot open (x86)\NAG\FL22\flw3222dcl\lib\'FLW3222DC_nag.lib

----------

Strangely enough, when I got back to my old Makefile (where I added the line from your code that was missing in mine, all: myprog.exe contourprog.exe), removed all blank lines, and also added a slash as an additional separator (although it was given in the LIBDIR, it also wanted to see the slash as $(LIBDIR)\$(LIBNAME) in the call)

Now my code works! With your help, I have managed to migrate the package, at last.

I am very grateful to you guys, many thanks to Steve, too!

I was stuck with this task for several weeks, and NAG support could not help me with compilation (well, with Christmas break making my silly questions even sillier for them, I assume).

Thank you both very much!

Yours sincerely

Valerie

We're glad to hear it!

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today