Skip to main content

Intel Parallel Studio 2019 meet Cygwin

Introduction

Intel Parallel Studio provides pre-configured bat to run command line interface using Windows CMD.  The command is called 'icl'. To some, this is satisfactory.  To me, I need a better shell.

Cygwin satisfies my need for a UNIX shell.  This post is about setting up a Windows system to successfully compile a simple code using Cygwin and icl, Intel C++.

Largely, I had two issues: one minor, quality-of-life issue, the other critical.

Quality-of-Life issue

The minor issue is that I wanted to simply double-click on the icon to open up a console with appropriate environment.  The provided bat file does that, but for CMD.  I wanted to gear that toward Cygwin bash environment.  The obvious way is to open up the CMD through the bat, and then execute Cygwin.bat from the Cygwin installation folder.

To have one-click icon to open up a prepared Cygwin bash console, we must provide appropriate arguments to the shortcut.

Method

  1. Locate the Intel-provided shortcut file called "Compiler 19.0 for Intel 64 Visual Studio 2017 environment" by going through the start menu and opening the folder location of the shortcut
  2. Make a copy of the shortcut and rename it appropriately (e.g. "Cygwin - Compiler 19.0 for Intel 64 Visual Studio 2017 environment")
  3. Right-click on the new shortcut and adjust the address
    • Add "&" character in the argument to add a new command
    • Add, after &, a command to execute Cygwin.bat
    • The end result will look something like the following: C:\Windows\System32\cmd.exe /E:ON /V:ON /K ""C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2019.0.117\windows\bin\ipsxe-comp-vars.bat" intel64 vs2017 & C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico - "
  4. Execute and see two windows open: first, CMD windows showing environment being set up, then Cygwin console with the bash promp.

Critical Issue

The second issue, if unaddressed, makes the process unusable.

Symptom

Given a cpp file called test.cpp, compilation is done by icl test.cpp This will generate test.obj and proceeds to link the file to the output file. The link process fails. The link process fails because of the path issue; essentially, wrong and incompatible link is called, causing the compilation process to fail.

Workaround

The issue is the path. The command link exists in /usr/bin of cygwin, as well as in the Intel Parallel Studio installation. When icl is used, like any command in shell, the bash goes through its PATH to find the first match of the command. In the default Cygwin installation, /usr/bin appears before the Windows-imported path. As such, link from GNU Coreutils is selected over the Intel compiler's. Therefore, a simple solution is the reverse the order of path such that Windows-imported path appears before Cygwin native paths. To do so, edit the /etc/profile and change the PATH variable: PATH="/usr/local/bin:/usr/bin${PATH:+:${PATH}}" Now, the correct link will be used to complete the compilation process.

Caveat

This method will now cause Cygwin to call wrong command if there are other commands with the same name in Windows installation. Possible solution is to create a script that will temporarily change the PATH, run icl, and change the PATH back. I will need to understand how Cygwin imports PATH from Windows to implement this.'

UPDATE 20180913

To implement the scenario in Caveat, I created a new shell variable, PATH_INTEL in /etc/profile right before the line with PATH and assigned the appropriate values favorable to icl and kept PATH to its original that placed cygwin bin first and Windows commands later. I also created a script called icl.sh that switched PATH before icl $* and switch it back afterwards. I then finally created an alias for icl that points to script instead. Now, the PATH does not interfere with the rest of the command while correct PATH is used while icl is being run.
Labels:

Comments

Post a Comment

Popular posts from this blog

Project: Boost-free goblins

The headache: Boost Don't take me wrongly: Boost library is a powerful set of tools for bleeding-edge technology. Much of it gets absorbed into the C++ Standard Libraries. The problem lies in our project being inactive for 7 years, which means it is relying on a library that is 7 years behind. Installing such an old library is a chore, and securing a pre-built package is problematic at best. The project is even incompatible with the later versions of Boost. It may have once given the original developers a powerful technology to propel their project in the past, but now we are stuck with clock stopped at 2011. Along with libtcod being stuck also in 2012, dealing with Boost is critical to bringing the project up-to-date. Options There are several ways to address the issue. Option 1 : Upgrade We can read each related source code, research how Boost has modified the relevant function calls, and either fix the expected return type or required input type, This may lead to mor...
Post a Comment
Read more

Vehicles with a Broken Frame

Browsing through github projects in C/C++ Trying to find ways to link up the goblin_camp project with more automated testers, I started looking around the Readme.md files of other C/C++ projects in github. From neovim, I found AppVeyor, and although I have not yet set it up, it promises to supplement Travis CI with Windows test builds. I also found Coverity Scan, which might be a way for us to scan the large, preexisting code and fix goblin_camp. Then, from Cataclysm-DDA, I found Bounty Source . The icon had a dollar figures on it, so I assumed it was some sort of funnily-named fund raising site. It was, but with a twist. Show Me The Money Apparently, this site is designed to help the project by having people put down money into a pot to fix certain issues listed in Github. Some of the issues were very popular: enough people contributed to the pot of 250 dollars. I would also imagine those are tough ones. I found myself a less-popular, 4 year-old issue of 15 dollars . I am mor...
Post a Comment
Read more

Project: Boost-free Goblins, Part 2

Last time at the goblin_camp The mad developers went on a warpath to rinse away Boost from the goblins. Loud yelling and crying was involved, 52 of them. But now that all the yelling is out of the way, how should we do this? Repetition, repetition, ... I am personally a very lazy programmer. If I can make computer do the job for me, I would have the computer do the job for me. While hunting down every instance of a library manually is doable in small number, as it was for cstdint, Other Boost libraries are more widely used and require much more effort scanning the text. Text. Text. Well, if we are talking about text-manipulation in sh ... Scripting my problem away My beloved hobby tools If it is not apparently already, I love automating tasks, and UNIX shell scripting had been my go-to solution for any binary scripting needs, especially in the days before I learned to program. This problem can be solved quite easily using few lines of scripts. Caveat We will be making a s...
Post a Comment
Read more