- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We just installed Intel Parallel Studio XE 2016 with Visual Studio 2013 already installed. When we open the command shell, we are getting errors as follows:
Copyright (C) 1985-2015 Intel Corporation. All rights reserved. Intel(R) Compiler 16.0 (package 110)
ERROR: Cannot determine the location of the VS Common Tools Folder.
c:\fortranfolder>ifort test.f
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel (R) 64, Version 16.0.0.110 Build 20150815 Copyright (C) 1985-2015 Intel Corporation. All rights reserved.
ifort: error #10037: could not find 'link'
Could you help with this error? We have software that relies on these commands.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If your VS is Express, this is expected, as automatic integration (even for command line) occurs only for the versions mentioned in the prerequisites docs (such as "community"). The ifort installer should have put up a menu showing any qualifying Visual Studio visible and asked for you to check the box if you want it included in the installation. Then the ifort cmd shell shortcut would pass automatically the vs2013 argument to run the vcvars.bat as well as setting up the ifort paths.
VS Express can support only 32-bit command line in any case, so it is not a preferred choice. ifort (but not other components of psxe) should offer to install with VS 2013 Shell, if it doesn't see a qualifying VS, but Microsoft requires that you first install the appropriate support kit, as the installer message will tell you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Tim - We have Visual Studio Professional 2013 installed (Version 12.0.21005.1 REL). We have reinstalled Intel Parallel Studio XE 2016 several times in an attempt to make sure it is connecting with Visual Studio. The Visual Studio Professional 2013 appears to be working well. We could reinstall both software packages again to verify all of the settings, unless you have another suggestion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just saw the same message working another customer issue and do not yet know the root cause. I will look into this immediately. Stay tuned....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In working with Michael we traced the origin of the ERROR shown in the original post to be issued by vcvars64 in his case. That error issues as a result of VS120COMNTOOLS being null.
While we are still trying to understand the root cause in Michael’s case, based on some leads from his research, it was found this error can also occur when C:\Windows\System32 is absent from the system PATH setting.
I am able to reproduce the error on my system after removing that entry from my system PATH setting. It is unknown what conditions or events might exist/occur to cause the removal of this entry from the system PATH setting; however, as in Michael’s case, the entry is present and yet he still experiences the error. I installed the same exact VS2013 and PSXE 2016 versions on my system as Michael had, and I did not experience this error.
If you experience this error, then as a first measure please check your system PATH setting for the C:\Windows\System32 entry and add it as needed to see whether that resolves the issue for you.
Other related reports:
http://community.wolfram.com/groups/-/m/t/438902?p_p_auth=Sj0s5NyO
https://schrievkrom.wordpress.com/2011/01/25/error-cannot-determine-the-location-of-the-vs-common-tools-folder/
As we learn more about Michael’s case we will update this post.
Updated: The issue was escalated Development also.
(Internal tracking id: DPD200377307)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
System32 could fall off the parsed section of PATH due to excessive number of entries in the System Environment Variables saved PATH setting. As discussed in the more recent thread, updating (or even reinstalling) Intel software tools can contribute to this, as there is no cleanup of old entries, even though the xe2016 may supersede some previous entries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I was considering that possibility too given the chain of initialization scripts executed that start with the Intel compilervars.bat and work their way into the Visual Studio initialization scripts.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page