building from batchfile

[newfortranuser]

Hi. When I learned that msbuild does not have a makerule for vfproj I was disappointed. When I looked at the obfuscation -- er, I mean documentation -- for msbuild my disappointment was replaced by reflief that I did not trap myself with msbuild. But I still need an unattended build process. So I tried devenv. It built my project just fine in Debug|Win32 but failed in Release|Win32. The linker could not find the svml lib. That's odd. I thought the vector libs were only used for x64 builds. The same Debug|Win32 configuration builds fine inside visual studio *and* the project files contain no references to the vector math libs. So I'm guessing (???) that the IVF/IDE integration automatically knows to include the link dependency in Release|Win32 even though it is not called out explicitly in any of the project files. Am I even close here?

Thanks.

[newfortranuser]

forgot to mention: ivf 11.1.054 and Visual Studio 2008

[Steven_L_Intel1]

The SVML library is used on IA-32 also. The compiler automatically adds a dependence on the SVML library in the object file. I would expect it to find it just the way it finds libifcore.lib, etc. Can you attach the .vfproj file for your project?

[newfortranuser]

1. Thanks for correcting my misunderstanding about the uses of SVML.

2. I'm sorry I cannot share my fortran_lib.vfproj file, but I can say that the linkage problem actually occurs when linking a static Fortran lib into the C++ (controled by main_prog.vcproj) which calls it.

3. When building in Visual Studio, the linkage is fine.

4. When building with devenv, the linkage fails on SVML.

Clearly devenv is not doing exactly the same thing Visual Studio is doing. Namely, Visual Studio is somehow magically resolving the dependency which I have not explicitly stated in either the vcproj file or the vfproj file. So I think my next step is to specifically call out the dependency on SVML in the vcproj. That should fix the linkage for devenv *and* probably make the sln more reliable in VS by replacing another instance of Visual Studio "magic" with something that actually won't break with the next release of VS.

If that does not work I will try to make up an example that reproduces it, but I'm not sure I know how to trigger IVF to use SVML. I might need some pointers on that.

Thanks!

[TimP]

ifort would always include SVML library in the link, unless you set /arch:IA32

[newfortranuser]

Steve and Tim,

Thanks for your help.

I am checking my project files against source control as I type. I think I hurt myself here andit might take a few hours to figure out. I have recently moved from 10.1.30 to 11.1.054 (with the corresponding change to vfproj files.) Right now, both Debug and Release are failing in VS2008 using a clean build. The failure is on svml_disp.lib in both cases. At least there is consistency. That's actually a good result.

I suspect my earlier partial success was the result of using leftover objects from a previous build. This is a very stable project *except* for the fact that I just switched from ivf 10.1 to ivf 11.1. I will report back after I run this to ground.

Also, thanks for the reminder about /arch:IA32. I have not yet mastered the richness of the ivf archietcture switches, but I appreciate them more every day.

[IDZ_A_Intel]

Visual Studio isn't doing anything for you here. The "magic" is in the compiler. It adds to the object file a linker "objcomment" directive naming the SVML library (along with other libraries used). When the linker processes the object file, it reads the directives and adds a reference to the library. The adding of the directive can be disabled with a compiler option (/libdir:noauto) and the processing of the directives can be disabled with a linker option.

If the library can't be found, then the list of folders VS looks in for libraries is not correctly set. This is specified under Tools > Options > Intel Visual Fortran > Compilers.

[newfortranuser]

I switched temporarily switched back to the 10.1 compiler and both Debug and Release build. We have a complex build environment (too complex) and it appears that my problem yesterday was that I may have been trying to link code compiled with 11.1 against libs from 10.1. Uh oh! Bad user! No cookie!

@Tim:

I decided to refresh my memory about the /arch switch while I was waiting for the build. Maybe I'm missing something, but I do not see /arch:IA32. I see pn1, pn2, pn3, pn4, SSE and SSE2. I am not specifying /arch, so the docs say it should pick pn4 by defaut. So I am a little surprised to see 11.1 trying to link with svml_disp.lib which I expected only for SSE or SSE2. My compiles are all using the Win32 configurations. Could you help me make sense of this? Obviously something important is missing from my understanding.

Thanks

[IDZ_A_Intel]

As of 11.0, the compiler defaults to /arch:SSE2 which will use SVML. I don't know where you are seeing pn1, pn2, etc. - are you looking at the ifort options?

/arch was a new option in 11.0. In 10.1, which defaulted to IA-32 code, the equivalent to /arch:SSE2 was /QxW.

[newfortranuser]

I found this in the 11.1.054 release notes:

When compiling for the IA-32 architecture, /arch:SSE2 (formerly /QxW) is the default as of
version 11.0. Programs built with /arch:SSE2 in effect require that they be run on a processor
that supports the Intel Streaming SIMD Extensions 2 (Intel SSE2), such as the Intel
Pentium 4 processor and non-Intel processors.

and in the onlien help for /arch I found this:

Default

pn4 The compiler optimizes for the Intel Pentium 4 processor

Does this mean that pn4 and SSE are treated as equivalent in all cases? If not, which is actually the default and what does it mean?

Thanks

[newfortranuser]

Guys, for some reason the clever visual editor in this forum is doing "interesting" things. The question at the end of my previous post appears inthe right-hand margin of the post. Very strange. In case you can't see it at all, my question is... is the default /arch:pn4 (per online help) or /arch:SSE (per release notes) and are these in fact the same? If they are different, how different? Thanks!

[newfortranuser]

Steve,

Our posts crossed in the ether. PLease see my followups. It looks like the CHM file is out of date. I access this by using teh Help menu in Visual Studio and selecting teh IVF Pro help.

Thanks!

[IDZ_A_Intel]

"pn4" is a CVF compatibility value and should not be used. The online help is correct, listing these at the bottom of the page for CVF compatibility.

The default in 11.0 is /arch:SSE2 (not /arch:SSE - you misread the release notes). This is equivalent to the CVF /arch:pn4.

[newfortranuser]

Ah. I see. I suspected as much. What I didn't tell you is that we libdir:noauto and libdir:nouser as part of our strategy to ensure that the project file is in full control of the build. Thanks to years of sloppy configuration (not by you guys!) we have been forced to take responsibility for cleaning up our messes. So we manage the include paths and lib paths explicitly for now, until we clean up our mess. Then we can go back to using the magic.

Makes sense now!

Thanks

[newfortranuser]

Steve,

I think we might be looking at different revisions of the online help or different pages in help. AFter installing 11.1.054, here is what I have verbatim:

arch, architecture

Determines the version of the architecture for which the compiler generates instructions.

IDE Equivalent

None

Architectures

IA-32 architecture, Intel 64 architecture

Syntax

Linux and Mac OS X:	-arch keyword
Windows:	/architecture:keyword

Arguments

keyword	Is the processor type. Possible values are:
	pn1	Optimizes for the Intel Pentium processor.
	pn2	Optimizes for the Intel Pentium Pro, Intel Pentium II, and Intel Pentium III processors.
	pn3	Optimizes for the Intel Pentium Pro, Intel Pentium II, and Intel Pentium III processors. This is the same as specifying arch pn2.
	pn4	Optimizes for the Intel Pentium 4 processor.
	SSE	Optimizes for Intel Pentium 4 processors with Streaming SIMD Extensions (SSE).
	SSE2	Optimizes for Intel Pentium 4 processors with Streaming SIMD Extensions 2 (SSE2).

Default

pn4	The compiler optimizes for the Intel Pentium 4 processor.

Description

This option determines the version of the architecture for which the compiler generates instructions.

On systems using IA-32 architecture, only keywords pn1, pn2, pn3, and pn4 are valid.

Alternate Options

Linux and Mac OS X: None

Windows: /arch

Note that there is nothign about CVF compatibility and nothing to suggest that pn4 is deprecated. Indeed, it is the stated default!

You are correct that I misquoted the release notes. Agreed: SSE2, not SSE. And I also see that /arch:IA32 is introduced in the release notes but does *not* appear anywhere in the online help I am looking at.

So my confusion seems to arise in part at least from the fact that my online help is out of date. I don;t know how that happened; I installed 11.1.054 myself.

Thanks for confirming that pn4=SSE2

Also, thank you for your exceptionally fast and clear responses. This has been kind of rapid-fire, so I'm going to go absorb this now.

[IDZ_A_Intel]

Ok - the online help you are reading is from 10.1. The 11.1 help looks very different.

[newfortranuser]

You are correct as always, Steve. With all my going back and forth between 10.1 and 11.1 I somehow managed to look at the 10.1 help every time. Argh! I think I need a vacation. Thanks for your patience.