OpenMP unresolved Links

[Kelli_Hendrickson]

If this is a duplicate post, I apologize.

A colleague and I have the same source code and solutions using MSV 2010. When I compile with /Qopenmp, I get the following error for only this omp call

error LNK2001: unresolved external symbol _OMP_GET_THREAD_NUM@0

As far as we can tell, the only difference is in the Build Environment. My colleague is using Build6 released in August and I am using Build8 released in December. The only other difference as far as I can tell is that my MSV was upgraded to SP1 for other project reasons. The details of the two installs are appended below.

Now, MSV SP1 broke the C compilers installed with Windows SDK 7.1, so I am concerned that it might have broken something with IVF. I did try and do a repair of the installation with no change.

Is there a specific place to look to ensure the openmp libraries are included? Or another starting point to try and determine where the installations differ?

Thanks,
Kelli

My installation:

Microsoft Visual Studio 2010

Version 10.0.40219.1 SP1Rel

Microsoft .NET Framework

Version 4.0.30319 SP1Rel

Installed Version: IDE Standard

Microsoft Visual Web Developer 2010 01011-532-2002361-70757

Microsoft Visual Web Developer 2010

Hotfix for Microsoft Visual Studio 2010 Professional - ENU (KB2542054) KB2542054

This hotfix is for Microsoft Visual Studio 2010 Professional - ENU.

If you later install a more recent service pack, this hotfix will be uninstalled automatically.

For more information, visit http://support.microsoft.com/kb/2542054.

Hotfix for Visual Studio 2010 Shell (Integrated) - ENU (KB2548139) KB2548139

This hotfix is for Visual Studio 2010 Shell (Integrated) - ENU.

If you later install a more recent service pack, this hotfix will be uninstalled automatically.

For more information, visit http://support.microsoft.com/kb/2548139.

Hotfix for Visual Studio 2010 Shell (Integrated) - ENU (KB2549864) KB2549864

This hotfix is for Visual Studio 2010 Shell (Integrated) - ENU.

If you later install a more recent service pack, this hotfix will be uninstalled automatically.

For more information, visit http://support.microsoft.com/kb/2549864.

Hotfix for Visual Studio 2010 Shell (Integrated) - ENU (KB2635973) KB2635973

This hotfix is for Visual Studio 2010 Shell (Integrated) - ENU.

If you later install a more recent service pack, this hotfix will be uninstalled automatically.

For more information, visit http://support.microsoft.com/kb/2635973.

Intel Visual Fortran Package ID: w_fcompxe_2011.8.278

Intel Visual Fortran Composer XE 2011 Update 8 Integration for Microsoft Visual Studio* 2010, 12.1.3520.2010, Copyright (C) 2002-2011 Intel Corporation

* Other names and brands may be claimed as the property of others.

Intel Inspector XE 2011 Update 7

Intel Inspector XE 2011 Update 7, (build 189290), Copyright 2009-2011 Intel Corporation. All rights reserved.

Intel VTune Amplifier XE 2011 Update 5

Intel VTune Amplifier XE 2011 Update 5, (build 186533), Copyright 2009-2011 Intel Corporation. All rights reserved.

Visual Studio 2010 Shell (Integrated) - ENU Service Pack 1 (KB983509) KB983509

This service pack is for Visual Studio 2010 Shell (Integrated) - ENU.

If you later install a more recent service pack, this service pack will be uninstalled automatically.

For more information, visit http://support.microsoft.com/kb/983509.


His installation:

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 01011-532-2002361-70861

Microsoft Visual Web Developer 2010

Intel Visual Fortran Package ID: w_fcompxe_2011.6.233

Intel Visual Fortran Composer XE 2011 Update 6 Integration for Microsoft Visual Studio* 2010, 12.1.3514.2010, Copyright (C) 2002-2011 Intel Corporation

* Other names and brands may be claimed as the property of others.

[Lorri_M_Intel · Accepted solution]

Are you using /iface:cvf ?

If so, please make sure that you have a USE OMP_LIB in your source program so that the correct
external name can be created.

--Lorri

[Steven_L_Intel1]

Lorri has the right answer, I am sure. If you had a USE OMP_LIB you would get the correct references. I do note that the Intel OpenMP library did have, at one time, STDCALL entry points, but these never worked right and were removed. (Reference DPD200172492).

[Kelli_Hendrickson]

Yes, we are use /iface:cvf.

I am confused in that if this is a source code issue why my colleague does not experience this issue. I have looked at the source and instead of using the OMP_LIB as you suggest, it decalrease the OMP_GET_THREAD_NUM function as an integer.

EDIT:
I modified the source and removed the integer declaration and added USE OMP_LIB in the source code and the issue is resolved. For our own understanding though, I would like to know why this is not an issue with my colleagues build environment and is for mine (is it the compiler build or something else?)

Thank you for the help.

[TimP]

Common legacy usage often has a local declaration
integer omp_get_thread_num instead of relying on USE OMP_LIB as the standard demands. That would normally work if you didn't use /iface:cvf and took care to leave integer size at default. The compiler doesn't have a list of library functions which must not be affected by /iface:cvf unless you give it one by USE.
The most common way people get /iface:cvf in their projects is by automatic conversion from CVF. It's probably better to switch away from /iface:cvf as soon as the basic conversion is complete.

[Steven_L_Intel1]

Hard to say. But using /iface:cvf without the USE would get you that entry point.

[Kelli_Hendrickson]

Thank you everyone. Including the library with the use statementresolved our issues and opened up an internal discussion for us on the requirement to continue to use /iface:cvf.