Intel Software Network articles feed http://software.intel.com/en-us/articles/intel-compilers/technical-notes/ en-us Building ACE/TAO with Intel(R) C++ Compiler for Windows XP 64-bit using Visual Studio
Introduction : 
This document explains how to build ACE/TAO using Intel(R) C++ Compiler for Windows XP 64-bit. From the ACE/TAO web site:

ACE† is an open-source framework that provides many components and patterns for developing high-performance, distributed real-time and embedded systems. ACE provides powerful, yet efficient abstractions for sockets, demultiplexing loops, threads, synchronization primitives.

TAO† (The ACE ORB) is an open-source implementation of a CORBA Object Request Broker (ORB) built using components and patterns in the ACE framework.
Several companies provide commercial support for ACE/TAO, see http://www.cs.wustl.edu/~schmidt/commercial-support.html† for information.


Version : 
The version of ACE/TAO used in this document is 5.7.2.
The 11.1.038 version of the Intel C++ compiler (Intel64) is used.


Obtaining Source Code : 
The ACE/TAO source code was downloaded from http://download.dre.vanderbilt.edu/†.


Prerequisites : 
- WinZIP or similar tool for extracting software archives
- Microsoft Visual Studio (2003, 2005 or 2008)


Configuration and Set-up information : 

1. Extract the archive into a path with no spaces in the path name (e.g., C:\ACE_wrappers).

2. Set ACE_ROOT, TAO_ROOT, and PATH environment variables.

For example, if ACE/TAO is installed in C:\ACE_wrappers, the variables should look like this:
ACE_ROOT=C:\ACE_wrappers
TAO_ROOT=%ACE_ROOT%\TAO
The PATH variable should contain these directories: %ACE_ROOT%\bin;%ACE_ROOT%\lib

Please follow these steps to set the environment variables:

- Log into an account with Administrator privilege
- Open the Control panel
- Click System
- Click the Advanced tab and then click the Environment Variables button
- Add new ACE_ROOT and TAO_ROOT variables
- Edit PATH variable from the System variables list
- Click OK

3. Create a file named config.h in %ACE_ROOT%\ace with the following contents:

#include "ace/config-win32.h"

4. Open the solution file that matches your version of Visual Studio.
For example, you could find following solution files:

%TAO_ROOT%\TAO_ACE.sln (Visual Studio 2003)
%TAO_ROOT%\TAO_ACE_vc8.sln (Visual Studio 2005)
%TAO_ROOT%\TAO_ACE_vc9.sln (Visual Studio 2008)

The projects in the TAO_ACE solution build the ACE and TAO libraries, TAO IDL compiler, gperf, ORB services
libraries and executables, and some common utilities. They do not include any examples, tests, or performance
tests. (Separate directories and solutions exist for them.) Libraries will be installed in %ACE_ROOT%\lib.
Some executables will be installed in %ACE_ROOT%\bin, others (the ORB services executables) will be installed
in their source directories.

5. It is necessary to update the solution to use the Intel(R) C++ Compiler.
In the Solution Explorer, select the solution and click the Use Intel C++ toolbar button.
Alternatively, select Intel C++ Compiler Pro > Use Intel C++ from the Visual Studio Project menu.
Click the OK button to continue.
The TAO_ACE solution constains many projects and it will take some time to update them to use Intel C++.

Finally, you should see the message in the output window with the list of the successfully updated projects.


6. Open Solution Properties and create a new platform configuration for x64 using the Configuration Manager.
Make sure, that current (target) configuration is Debug|x64 or Release|x64 and build solution (Build > Build Solution).


During building of the solution, go to the Output window to verify that the Intel C++ Compiler is used. If Intel C++ Compiler is used, you should see a message similar to the following:

Compiling with Intel(R) C++...[Intel(R) 64]... (Intel C++ Environment)


Verifying Correctness

There are many examples and tests included in ACE/TAO. Additional separate directories and solutions exist for them.
It is possible to compile all tests using corresponding test solution files from %ACE_ROOT%\tests folder.
There is one solution file for all tests (each for different versions of VS) there, however, it is also possible to compile each test separately.

For example, you could compile ACE_Test to verify the correctness of ACE compilation using following instructions:

1. Open ACE_Test project file from %ACE_ROOT%\tests folder (e.g.,ACE_Test_vc9.vcproj for VS2008).

2. It is necessary to update the solution to use the Intel(R) C++ Compiler. Please follow the same instructions as described previously in step 5. You will be also asked to save the solution.

3. Make sure, that current (target) configuration is Debug|x64 or Release|x64 (it should be the same with the compiled libraries) and build solution.

4. Run the test (F5 or Ctrl+F5).

5. You could check the logs in %ACE_ROOT%\tests\log folder (ACE_Test.log file). In case of normal execution the output looks like this:

Sep 08 15:52:11.103 2009@LM_DEBUG@(3820|5884) Starting ACE_Test test at Tue Sep 8 2009 15:52:11.103000
Sep 08 15:52:11.103 2009@LM_DEBUG@(3820|5884) Ending ACE_Test test at Tue Sep 8 2009 15:52:11.103000


Source Code Changes : 
None required.


Related topics: 
http://software.intel.com/en-us/articles/building-acetao-with-intelr-c-compiler-for-linux/


Known Issues or Limitations : 
None. Please contact Intel® Premier Support website or Intel® User Forums if you encounter problems or want to provide feedback.

† This link will take you off of the Intel Web site. Intel does not control the content of the destination Web Site.
]]> http://software.intel.com/en-us/articles/building-acetao-with-intelr-c-compiler-for-windows-xp-64-bit-using-visual-studio Tue, 08 Sep 2009 05:19:48 -0700 http://software.intel.com/en-us/articles/building-acetao-with-intelr-c-compiler-for-windows-xp-64-bit-using-visual-studio#comments http://software.intel.com/en-us/articles/building-acetao-with-intelr-c-compiler-for-windows-xp-64-bit-using-visual-studio Open Source Intel® Compilers Intel® C++ Compiler for Windows* Knowledge Base How to find Host ID for Floating licenses
Identifying the Host Name and Host ID
The host name and host ID are system-level identifiers on supported platforms that
are used in the license file to identify the node on which you plan to install the Intel
License Manager for FLEXlm* and license file. To enable you to obtain a counted
license, these unique values must be available when you register your product. For
node-locked licenses, you will also need the host name and host id of the node from
which your applications will run, if different from the node for the Intel License
Manager for FLEXlm*. Follow these directions to obtain the host name and host id for
each supported platform:

Microsoft Windows*
1. From the Start menu, click Run...
2. Type cmd in the Open: field, then click OK.
3. Type ipconfig /all at the command prompt, and press Enter.
In the resulting output, host name is the value that corresponds to Host Name, and
host id is the value that corresponds to Physical Address.

For example, if the output of ipconfig /all included the following:
Host Name . . . . . . . : mycomputer
. . .
Physical Address . . . . : 00-06-29-CF-74-AA
then host name is mycomputer and the host ID is 00-06-29-CF-74-AA.

Linux*
1. Run the hostname command to display the host name.
2. Run the command /sbin/ifconfig eth0 to display the hardware address.
For example, if the /sbin/ifconfig eth0 command returns
HWaddr 00:D0:B7:A8:80:AA, then the host ID is 00:D0:B7:A8:80:AA.
It is strongly recommended that users run the lmhostid utility to obtain the hostid
value required to generate the counted licenses. The lmhostid utility can be found in
the install location to which Intel License Manager for FLEXlm* is installed.

Mac OS* X on Intel® Architecture
1. Run the hostname command to display the host name.
2. Run the command /sbin/ifconfig en0 ether to display the hardware address.
The following is an example of an address that could be returned by this command:
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:13:20:60:23:4f
It is strongly recommended that users run the lmhostid utility to obtain the hostid
value required to generate the counted licenses. The lmhostid utility is installed to
the same location as the Intel License Manager for FLEXlm*.

]]> http://software.intel.com/en-us/articles/how-to-find-host-id-for-floating-licenses Thu, 13 Aug 2009 09:15:55 -0700 http://software.intel.com/en-us/articles/how-to-find-host-id-for-floating-licenses#comments http://software.intel.com/en-us/articles/how-to-find-host-id-for-floating-licenses Software Products General Intel® Compilers Intel® License Manager for FLEXlm* Knowledge Base Intel® Software Development Products Registration Center Knowledge Base Different result of Volatile variables between icc and vc Problem : 

We used keyword "volatile" as below when defining a variable,:

volatile int i=5;

The volatile has multiple meanings. To a compiler writer it means to take no code generation shortcuts when accessing such an object. "Volatile" is reminder to compiler to not suppose or guess some conditions when optimized, the variable could be change by some unexpected elements anytime.

So, the variable i should be stored in SRAM, every time we used it, we read it from SRAM.

Let's see a simple case:

// tstcase.c
include <stdio.h>
include <stdlib.h>

void foo()
{
volatile int i=1, j=1;
i=(i++)+(j++)+2;
j=i=i++;
printf("i=%d,j=%d\n",i,j);

}

Using Intel C++ compiler, result is:

i=3,j=2 (same result with gcc)

Using VC compiler, result is

i=6,j=5

I thinks that i=(i++)+(j++)+2 was translated to:

Intel C++ compiler:

t=t+t1+2; (t is equal to 4)
t++; (t is equal to 1, then execute t++, t is equal to 2)
t1++; (t1 is equal to 2)
Then, j=i=i++;
Output is i=3,j=2

Microsoft C++ compiler :

t=t+t1+2; (t is equal to 4)
t++; (t is equal to 5)
t1++; (t1 is equal to 2)
Then, j=i=i++;
Output is i=6,j=5.

If we did not use Volatile, we got same result(i=6,j=5) no matter which compiler used. If integrated Intel C++ compiler to VS2008, compiled both with VC and icl , we got different result.

Environment : 
Windows, Linux , Intel C++ compiler, Microsoft C++ compiler, gcc

Root Cause : 
The statements use language constructs that have undefined behaviour according to C/C++ standard:

Resolution : 

The test uses language constructs that have undefined behaviour according to C/C++ standard:

>>> i=(i++)+(j++)+2;
>>> j=i=i++;

The value of i is being modified more than once between two sequence points. Refer to the rules for expressions (section 5, paragraph 4 of the ISO C++ standard):

"Except where noted, the order of evaluation of operands of
individual operators and subexpressions of individual
expressions, and the order in which side effects take place,
is unspecified. Between the previous and next sequence
point a scalar object shall have its stored value modified at
most once by the evaluation of an expression. Furthermore,
the prior value shall be accessed only to determine the value
to be stored. The requirements of this paragraph shall be met
for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined.

[Example:
i = v[i++]; // the behavior is unspecified
i = 7, i++, i++; // i becomes 9
i = ++i + 1; // the behavior is unspecified
i = i + 1; // the value of i is incremented
-end example]"


]]> http://software.intel.com/en-us/articles/different-result-of-volatile-variables-between-icc-and-vc Mon, 13 Jul 2009 23:20:19 -0700 http://software.intel.com/en-us/articles/different-result-of-volatile-variables-between-icc-and-vc#comments http://software.intel.com/en-us/articles/different-result-of-volatile-variables-between-icc-and-vc Intel® Parallel Composer Intel® Compilers Intel® C++ Compiler for Linux* Knowledge Base Intel® C++ Compiler for Mac OS X* Knowledge Base Intel® C++ Compiler for Windows* Knowledge Base Intel® Parallel Composer Knowledge Base compilation failure if function mm_load_pd1() is invoked
Problem : 
  When compiling an application will function call to mm_load_pd1, the Intel compiler will report that mm_load_pd1 is not found. gcc compiler can successfully build the application.

Environment : 

Intel compiler 11.0, 11.1
gcc 4.3


Resolution : 
Please use the standard name mm_load1_pd() instead of mm_load_pd1(). gcc can also recognizes this standard name for this operation.

]]> http://software.intel.com/en-us/articles/compilation-failure-if-function-mm_load_pd1-is-invoked Sun, 12 Jul 2009 21:53:41 -0700 http://software.intel.com/en-us/articles/compilation-failure-if-function-mm_load_pd1-is-invoked#comments http://software.intel.com/en-us/articles/compilation-failure-if-function-mm_load_pd1-is-invoked Intel® Compilers Q&A from Webinar: Find Errors in Windows* C++ Parallel Applications On April 14, 2009 Bernth Andersson presented a technical session and live demo webinar focusing on the Intel(R) Parallel Debugger Extension and it's use for identifying parallel coding issues and run-time problems related to concurrency. Below are questions that came up during this webinar and answers to those questions.  

Q1. Can you disable a single specific parallel region?

A: The "Serialize Parallel Region" option of the Intel(R) Parallel Debugger extensions temporarily sets the OpenMP* omp_set_num_threads() environment variable to 1, thus forcing single threaded execution even on a multi-core system. This temporary change applies to the next parallel block or parallel region in your code relative to the current EIP or program counter location.

Thus, yes - the "Serialize Parallel Region" option can be applied to a specific parallal region of your choice. You can do so by setting a breakpoint just before you enter the parallel region you would like to have executed as a single serial thread and then selecting the serialization option from the Intel(R) Parallel Debugger Extension menu inside Microsoft* Visual Studio. 


Q2. Do the Parallel Debugger Extensions only support OpenMP* or also native Windows* threads or Threading Building Blocks? 
A: Most of the Parallel Debugger Extension features like Thread Data Sharing Event Detection, Function Reentrancy Detection amd Serialize Parallel Region, rely on instrumentation of debug information and on the OpenMP* library. As such these features are currently only available for OpenMP* based threading. The one feature that is independent of the threading model used are the enhanced and highly configurable SSE register windows.

Q3. Do the Intel(R) Parallel Debugger Extensions use similar instrumentations as the Intel(R) Parallel Inspector? 
A: The debug symbol information instrumentation done by the Intel(R) C++ Compiler when the /debug:parallel option is set along with /Zi is different from the code instrumentations used by the Intel(R) Parallel Inspector for it's instrumentation assisted operating mode.
The Intel(R) Parallel Debugger Extensions do not rely on executable code instrumentation, but rather on instrumentation of the symbol information used for debugging. As such the Parallel Debugger Extensions cannot statically anaylze the execution flow, but rely on a detectable event that may be of interest happening at real time during a debug session. At the same time, because only the debug information is instrumented there should only be very minimal performance impact on the execuatble if run outside the Microsoft* Visual Studio Debugger.

Q4. Is the compiler option /Qpenmp required for use of the Intel(R) Parallel Debugger Extension?
A: Yes, all enhanced parallelism features of the Intel(R) Parallel Debugger Extensions rely on OpenMP* based threading, except for the SSE register windows.

Q5.  Do the Intel(R) Parallel Debugger Extensions require the use of the Intel(R) Compiler?
A: Yes, the Parallel Debugger Extensions rely on debug info instrumentation added with the Intel(R) Compiler option /debug:parallel in conjunction with /Qopenmp. Therefore the full capabilities of the Intel(R) Parallel Debugger Extensions are only available when used with the Intel(R) Compiler.

Q6. Can I use the Intel(R) Parallel Debugger Extensions to debug parallelism in the Intel(R) Integrated Performance Primitives and to serialize execution in them?
A: In principle yes, BUT this would require rebuilding and relinking the Intel(R) IPP with symbol information and /debug:parallel. Since you are most likely taking the primitives from prebuilt libraries that you link into your project, this not really a supported usage model, although it may work in some cases depending on how the call to the Intel(R) IPP function of your choice is embedded in the rest of your application.
The short answer thus is really no, with some exceptions.

Q7.  Does the OpenMP* library have to be linked in statically? Can 3rd party OpenMP* libraries be used?
A: The OpenMP* library can be linked in statically or dynamically into your application build for the use of the Intel(R) Parallel Debugger Extension. The OpenMP* library used by the Intel(R) C++ Compiler is really a standard OpenMP* library. However, there is the dependency on the debug information instrumentation using /debug:parallel. This instrumentation has only been tested and is only expected to work with the OpenMP* libraries provided with the Intel(R) Compiler.

Q8. What is the main benefit of the SSE Register Window? Does it depend on OpenMP*?
A: The SSE Register Window allows you to group the display of the register contents and display said contents in the exact way that you are using it in your parallelized loops, your structured arrays or other parallel structures. By doing this the highly configurable SSE Register Window provides you with the link between your data as it is used in your application and the way this very same data is actually stored and processed in the SSE registers.

This can be quite valuable for understanding more complex heavily parallel multimedia or graphics code for instants.

This feature does not rely on any instrumentation or any specific threading implementation. It is independent of OpenMP*. 

For additional questions please also refer to the Intel(R) Parallel Debugger Extension article and whitepaper at http://software.intel.com/en-us/articles/parallel-debugger-extension/ ]]> http://software.intel.com/en-us/articles/qa-from-webinar-find-errors-in-parallel-applications Tue, 30 Jun 2009 16:56:46 -0700 http://software.intel.com/en-us/articles/qa-from-webinar-find-errors-in-parallel-applications#comments http://software.intel.com/en-us/articles/qa-from-webinar-find-errors-in-parallel-applications Parallel Programming Intel® Compilers Intel® Parallel Composer Knowledge Base Intel Compilers for Linux Version 11.1 Silent Installation Guide Linux Compiler Professional 11.1 Special Installation Instructions

Linux Compiler Professional 11.1
"Silent" or "Non-interactive" Installation Instructions


Contents:



Silent Command Line Installations

Starting with release 11.0, the Linux installation programs for Compiler Professional are built using the PSET (Program Startup Experience Technologies) 2.0 core.  This PSET core is a framework of tools built by Intel to provide a robust set of installation and licensing features that are consistent across Intel product lines.  A similar PSET core is used for the Windows* and Mac OS* X installation packages as well.

One feature provided in the PSET core is support for the "silent" install.  Historically, "silent" really meant "non-interactive".  At this point, "silent" also means "does not report copious amounts of information".  The silent install really is silent now, assuming there are no problems during the installation.  The silent install method allows the user to perform a command line installation of an entire package with no need to answer prompts or make product selections.

A historical note specific to Linux installs: there has been a "silent" install capability in the Linux Compiler products since version 9.0.  This legacy version, included in versions 9.1, 10.0, 10.1, and 11.0 as well, performed the same function.  But starting with version 11.1, the legacy silent install embedded in the "inner install components" has been removed.  The new PSET core silent install is the only method still supported - that is, older silent installation tools in v11.0 and older are no longer supported other than the RPM command line install method (see details on RPM-based installs below).

Silent Install Steps: "From Scratch"

To run the silent install, follow these steps:

  • Make sure that a working product license is in place before beginning.  The file should be world-readable and located in a standard Intel license file directory, such as /opt/intel/licenses.
  • Create / edit a silent install INI file.  Here is an example file.  A similar file can be edited and placed in any directory on the target system.

ACTIVATION=exist_lic
CONTINUE_WITH_INSTALLDIR_OVERWRITE=yes
CONTINUE_WITH_OPTIONAL_ERROR=yes
PSET_INSTALL_DIR=/opt/intel/Compiler/11.1/038
INSTALL_MODE=RPM
ACCEPT_EULA=accept

  • Run the silent install.  For example, if you untarred your compiler package in /tmp for version 11.1.038:

prompt> cd /tmp/l_cproc_p_11.1.038

prompt> ./install.sh --silent /tmp/my_silent_config.ini

prompt>

That's it! The silent install is complete.

A few comments on the fields inside the silent install INI file:

  • ACTIVATION=exist_lic

This tells the install program to look for an existing license during the install process.  This is the preferred method for silent installs.  If you have only a serial number, please visit https://registrationcenter.intel.com to register your serial number.  As part of registration, you will receive email with an attached license file.  Save the license file in /opt/intel/licenses/ directory.  If you have already registered your serial number but have lost the license file, revisit https://registrationcenter.intel.com and click on the hyperlinked product name to get to a screen where you can cut and paste or mail yourself a copy of your registered license file.

  • CONTINUE_WITH_INSTALLDIR_OVERWRITE=yes

This tells the installer that it is OK to write into an existing directory.  This should be set to "yes" especially in the case where a C/C++ installation will be written into the same major product tree as a Fortran installation from the same packaging cycle (e.g. l_cproc_p_11.1.038 and l_cprof_p_11.1.038).

  • CONTINUE_WITH_OPTIONAL_ERROR=yes

This tells the install program that if the optional, non-critical prerequisite checks should fail to detect a needed element, the installation should continue anyway.  Optional checks include operating system types and/or versions, presence of a compatible Java Run-time Environment (JRE), etc.  Note that non-optional (i.e. mandatory) prerequisite checks cannot be ignored by the silent install process.  These include such things as required installed programs, commands needed by the installer and/or the product itself (e.g. grep, cut, etc. for the installer and g++ for the compilers).  MAKE SURE YOUR LINUX DISTRO HAS INSTALLED DEVELOPMENT ENVIRONMENT, including gcc, g++, binutils, etc.  Many Linux distributions come as 'desktop' images and may not have all the gcc toolchain needed for developing applications by default.  Use your package manager to find and download all needed gcc and g++ toolchains.  Also, it is required to keep gcc and g++ at the same version - do not update one and not the other.  Keep them at the same version.

  • PSET_INSTALL_DIR=/opt/intel/Compiler/11.1/038

This is the install directory where product content will be placed.  Permissions for the parent directories and file systems of this directory need to be enabled so that the user running the silent install could create them, but the directory itself does not need to exist prior to the installation.

  • INSTALL_MODE=RPM

This directive tells the install program that the RPM method should be used to install the software.  This will only work if the install user is "root" or has full root priveleges and your distribution support RPM for package management.  In some cases, where the operating system of the target system does not support RPM or if the install program detects that the version of RPM supported by the operating system is flawed or otherwise incompatible with the install program, the installation will proceed but will switch to non-RPM mode automatically.  This is the case for certain legacy operating systems (e.g. SLES9) and for operating systems that provide an RPM utility, but do not use RPM to store or manage system-installed operating system infrastructure (e.g. Ubuntu, Debian).  THUS, Ubuntu and Debian users set this to INSTALL_MODE=NONRPM.

If the you do not want to use RPM, then this line should read "INSTALL_MODE=NONRPM".  In this case, the products will be installed to the same location, but instead of storing product information in the system's RPM database, the Intel product install information will be stored in a flat file called "intel_sdp_products.db", usually stored in /opt/intel (or in $HOME/intel for non-root users).

  • ACCEPT_EULA=accept

This tells the install program that the invoking user has agreed to the EULA, or end user license agreement.  If this is not present in the INI file, the installation will not complete.

Note that silent install using this format does not currently support pre-selection of individual components.  In other words, if the desired installation is intended to include only some of the install components, but not all of them, the INI file here will not support this.  A custom INI created with the duplicate method will install all of the components available in a specific package.  If a custom install operation that only installs specific portions of the components is desired, it is suggested that the RPM install method be used for this.  (See below)


Silent Install Steps: "Copy and Repeat" Method of INI Creation

If you need to make the same sort of installation over and over again, one way to get the INI file right the first time is to run the installation program once interactively, using the options that meet the local needs, and record these options into an INI file that can be used to replicate this same install via silent install for future installations.

To do this, the user simply needs to add the "duplicate" option to the script invocation, and run a normal install, as follows:

prompt> ./install.sh --duplicate /tmp/my_install.ini

This "dash dash duplication" option will put the choices made by you into the file specified on the command line.  You can modify this recorded INI file as appropriate, then use it to perform additional or repeat installs.  The INI file created with this method may include a line "CONTINUE_WITH_INSTALLDIR_OVERWRITE" without the "=yes" on the end.  You will need to manually edit this INI file to add an "=yes" or "=no" to the end of this line, or else remove the CONTINUE_WITH_INSTALLDIR_OVERWRITE line altogether.  This limitation will be addressed in a future release.

Note that silent install using this format does not currently support pre-selection of individual components.  In other words, if the desired installation is intended to include only some of the install components, but not all of them, the INI file here will not support this.  A custom INI created with the duplicate method will install all of the components available in a specific package.  If a custom install operation that only installs specific portions of the components is desired, it is suggested that the RPM install method be used for this.  (See below)

RPM Command Line Installations

The files associated the Linux Compiler Professional products are stored in "RPM" files.  RPMs (short for Red Hat Package Manager).  They are grouped according to certain file type guidelines.  Each major product component will consist of one more or of these RPMs.  For non-RPM systems and for users who choose to install the product without using the RPM database of their target systems, an "underneath the hood" utility is embedded inside the installation program tools to extract the contents of the RPM files.

Changes for RPM in 11.1

Starting with the 11.1  packages, the Linux Compiler Professional packaging includes RPM files that also contain embedded installation functionality.  This means that key install behaviors such as environment script updating and symbolic link creation, which used to be only in the install program itself, are now embedded in the RPM files.  As a result, the experienced user can make use of the RPM files directly in order to install and remove Linux Compiler Professional 11.1 products.

Warning: this is truly for the experienced, Linux system savvy user.  Most RPM command capabilities require root privileges.  Improper use of rpm commands can corrupt and destroy a working system.

The changes done for the 11.1 Linux product are intended to ease the job of deploying the Linux Compiler Professional solution sets in enterprise deployments, including cluster environments. 

Product Layout for 11.1

The format of the install packages themselves was changed for 11.1.  Here is an example (for C++ package 11.1.038.

Top directory contents of l_cproc_p_11.1.038 package:

  • cd_eject.sh - CD eject script used by install.sh
  • install.sh - install script
  • license.txt - end user license agreement
  • pset - installation and licensing content directory
  • Release_NotesC.pdf - product release notes
  • rpm - directory containing all product content in RPM file format, plus the EULA and LPGL license

This is the RPM directory (l_cproc_p_11.1.038/rpm) layout for the 11.1 beta C/C++ product (IA-32 example):

  • clicense - product EULA
  • lgpltext - LGPL Eula
  • intel-cproc038-11.1-1.i486.rpm - architecture-specific (IA-32) C/C++ compiler content
  • intel-cprocsdk038-11.1-1.noarch.rpm - architecture-neutral core C/C++ compiler content
  • intel-cproidb038-11.1-1.i486.rpm - architecture-specific (IA-32) debugger run-time files
  • intel-cproidbsdk038-11.1-1.noarch.rpm - architecture-neutral debugger content
  • intel-cproipp038-11.1-1.noarch.rpm - architecture-neutral IPP content
  • intel-cproipplib038-11.1-1.i486.rpm - architecture-specific (IA-32) IPP run-time libraries
  • intel-cproipplibdev038-11.1-1.i486.rpm - arch-specific (IA-32) IPP development libraries
  • intel-cprolib038-11.1-1.i486.rpm - architecture-specific (IA-32) C/C++ run-time libraries
  • intel-cprolibdev038-11.1-1.i486.rpm - architecture-specific (IA-32) C/C++ devel libraries
  • intel-cpromkl038-11.1-1.noarch.rpm - architecture-neutral MKL content
  • intel-cpromklib038-11.1-1.i486.rpm - architecture-specific (IA-32) run-time libraries
  • intel-cpromklibdev038-11.1-1.i486.rpm - architecture-specific (IA-32) devel libraries
  • intel-cprotbblib038-11.1-1.noarch.rpm - architecture-neutral TBB run-time libraries
  • intel-cprotbblibdev038-11.1-1.noarch.rpm - archtecture-neutral TBB devel libraries and content

    (Note: TBB is special case "one RPM fits all" packaging)

This is the RPM directory layout for the 11.1 beta Fortran product (IA-32 example):

  • flicense - product EULA
  • intel-cprof038-11.1-1.i486.rpm - architecture-specific (IA-32) Fortran compiler content
  • intel-cproflib038-11.1-1.i486.rpm - architecture-specific (IA-32) Fortran run-time libraries
  • intel-cprofsdk038-11.1-1.noarch.rpm - architecture-neutral Fortran compiler content
  • intel-cproidb038-11.1-1.i486.rpm - architecture-specific (IA-32) debugger content
  • intel-cproidbsdk038-11.1-1.noarch.rpm - architecture-neutral debugger content
  • intel-cprolib038-11.1-1.i486.rpm - architecture-specific (IA-32) C/C++ run-time library content
    (required for Fortran - same as the file included in the above C/C++ package)
  • intel-cprolibdev038-11.1-1.i486.rpm - architecture-specific (IA-32) C/C++ devel library content
    (required for Fortran - same as the file included in the above C/C++ package)
  • intel-cpromkl038-11.1-1.noarch.rpm - architecture-neutral MKL content
  • intel-cpromklib038-11.1-1.i486.rpm - architecture-specific (IA-32) MKL run-time libraries
  • intel-cpromklibdev038-11.1-1.i486.rpm - architecture-specific (IA-32) MKL devel libraries

Installing Compilers With the RPM Command Line

To install an 11.1 Linux Compiler Professional solution set via RPM command line, you should first ensure that a working license file or other licensing method (such as floating or network-served licenses) is already in place.  There is no license checking performed during RPM installation.  However, if you install without a license file you will get an 'cannot check out license' error when you try to use the compiler.

You are assumed to have complied with the End User License Agreement if you are performing an RPM command line installation.  The EULA is present in the parent installation tarball, and again duplicated inside the 'rpm' directory.  Please read this license agreement.  It is assumed you agree to this license agreement if you proceed with an rpm installation.

Once a license file or license method is in place, the user can install the products directly with these simple steps:

  • Login as root or 'su' to root
  • 'cd' to the package/rpm directory ( e.g. /tmp/l_cproc_p_11.1.038/rpm )
  • Run the install command

prompt> rpm -i *.rpm

This completes without error in most cases.  If some system-level prerequisites, for required system libraries for example, are not met by the target operating system, a dependency warning may be returned by the rpm install.  There are no embedded detailed dependency checks inside the RPM install capabilities for required commands such as g++ or for optional requirements such as a valid supported operating system or supported JRE.  The embedded requirements are kept simple to ease installation for the general case, with two primary exceptions.  The first is requirement for a /usr/lib/libstdc++.so.5 to exist on the target system, and must match in 64bit or 32bit (there will be 2 copies of this library, one 64bit and one 32bit in 2 separate /lib paths, if you wish to be able to compile in 64bits and 32bits).  If libstdc++.so.5 is not available for your distribution but libstdc++.so.6 is, make libstdc++.so.5 a symbolic link to the .6 version. 

The second requirement is that the target operating system have at least the 3.0 version of "lsb" component installed.  Availability of this LSB component will, in the vast majority of cases, also ensure that other necessary system level libraries are available.  See LSB Support below for more information on getting the 'lsb' capability onto a target system.

If you believe that you have effectively installed the correct requirements on the target system and the dependency failures still persist, there is a fallback option, the "--nodeps" (dash dash nodeps) rpm switch.  Invoking 'rpm -i' with the --nodeps option will allow the rpm installation to succeed in most cases.

prompt> rpm -i --nodeps *.rpm

Again, this will get you past the perceived dependency issues, which may be unique to a particular distribution of Linux and not really a problem for the resulting installation.  But there is no assurance of complete success other than testing the resulting installation.

Other Special RPM Install Cases

If you are installing RPMs using the rpm command line, but using a multi-architecture package (such as the "combo" IA-32 / Intel64 package or a DVD package), you may want to install all of the RPMs that match their specific target machine's architecture.  Or, if you are installing onto an Intel64 system and want to include both the IA-32 and Intel64 components, you may want both of these included.  Here are some example rpm command line invocations:

prompt> rpm -i *.noarch.rpm *.i486.rpm

(installs all components needed for operation of IA-32 products)

prompt> rpm -i *.noarch.rpm *.i486.rpm *.x86_64.rpm

(installs all components needed for operation of IA-32 and Intel64 products)

prompt> rpm -i *.noarch.rpm *.ia64.rpm

(installs all components needed for operation of IA-64 products)

Certain Linux distributions do not like the idea of two RPM files having the same base name.  For example, the rpm versions of certain distros might complain that there is more than one instance of  intel-cproc023-11.1-1 on the command line when installing both the IA-32 and Intel64 RPMs onto the same machine.  For these distros, use the "--allmatches" ( dash dash allmatches ) command line switch:

prompt> rpm -i --allmatches *.noarch.rpm *.i486.rpm *.x86_64.rpm

Optionally, you may need to use the --force ( dash dash force ) switch in some cases.

Customizing the RPM Command Line

The rpm command has a long list of available options, including hooks to install from FTP and HTTP RPM repositories, features to examine contents of installed RPM-based programs and uninstalled RPM package files, etc.  Most of these are beyond the scope of this document.  See the Links section for references to external documentation on RPM.  Here are a couple of additional RPM switches, however, which may be routinely useful.

prompt> rpm -i --prefix /opt/intel/Compiler/11.1/035TEST *.rpm

( tells rpm to use /opt/intel/Compiler/11.1/023TEST as the target install directory)

prompt> rpm -i --replacefiles *.rpm

( tells rpm to replace any existing files on the system using the new RPM files)

prompt> rpm -i --replacepkgs *.rpm

( tells rpm to replace any existing package on the system using the new RPM files, even if they are already installed ... this may be useful in test applications where newer versions of a package with the same name are being tested )

Uninstallation Using RPM

Since the installation of Linux Compiler Professional 11.1 packages includes in its deliver all of the uninstall scripts, the easiest way to perform a product uninstall is to simply run the uninstall script that is created by the install process.  If you have a need to automate rpm-based uninstalls, however, a couple of "tricks" can be employed to make this simpler.  These should be used with caution, as with any system command performed from a privileged account.

Here is an example command line that will remove all RPM packages from a Linux Compiler Professional 11.1 package number "038":

prompt> rpm -e --allmatches `rpm -qa | grep intel-cpro | grep 038 | grep 11-1`

Note use of back-quotes.

Some Linux distributions will also complain about "multiple matches" during the uninstall process.  In this case, the "--allmatches" switch mentioned above can also be employed here.

A Short Word on Updates

The rpm structure and command set support the application of updates or "patches" to existing installations.  For example a util-1.1-2.rpm package may be issued that adds fixed content to some pre-existing util-1.1-1.rpm.   The existing release process for Linux Compiler Professional includes support for "version co-existence" or multiple installs of separate product versions.  So each new iteration of the product is unique from the previous version.  This means that Compiler Professional 11.1 packages are not available in "patch" form.  All product releases are stand-alone versions.  So use of the 'rpm -U' upgrade capability is not supported by our product delivery model at this time. 

LSB Support

LSB, or Linux Standard Base, is an effort sponsored by the Linux Foundation (http://www.linuxfoundation.org) to improve the interoperability of Linux operating systems and application software.  Intel is a major participant in Linux Foundation activities and has embraced LSB as a viable means of improving our products and our customers' use of those products.  To that end, we have included establishing LSB compliance as a part of our goals for our products and software packages in the future.

For the purposes of the Linux Compiler Professional 11.1 release, our primary objective is to product packages that adhere to LSB packaging requirements.  Most of the RPM changes mentioned above were done for this purpose.  To be specific, however, we should draw a distinction between product compliance and package compliance.  Because our compiler products must support a vast array of legacy constructs, the applications themselves may or may not be "certifiable" within the LSB guidelines, but our packages, i.e. our RPMs and install programs should be.  This is the primary reason for inclusion of the "lsb >= 3.0" embedded requirements being added to our RPMs.

Some of these Linux distributions come with LSB support already included in the operating system by default (e.g. SLES11).  For others, an external or optional package must be installed.  If supporting an environment that is using RPM command line installation and want to enable that site / system / systems to be able to install without using the dreaded "--nodeps" option, the best best is to acquire and install the companion LSB solution for that operating system.

The Linux Foundation website contains links to download resources for LSB, as to many of the vendor-specific support sites.  Check out these sites for information on adding LSB support to an existing operating system.

For RPM-based systems, a user can check on the status of LSB for their system, using a command like this:

prompt> rpm -q --provides lsb

This will tell if an 'lsb' RPM package is already installed and, if so, what version.

For our non-RPM supported operating systems, Ubuntu and Debian, the privileged user can use the Debian 'apt-get' facility to easily install the latest version of LSB supported by the specific distribution:

prompt> apt-get install lsb

Redistribution Package Installations

Redistribution packages allow applicaitons built with the Intel compilers to be run on client systems that do not have the Intel compilers installed (i.e. end-user systems).  These are ONLY needed on systems without the Intel compilers installed. A redistribution package has all the Intel dynamic libraries possibly needed for a dynamically linked application.  Alternatively, you can explore to -static-intel compiler switch to statically link all required Intel libraries into an application.  Redistribution packages were officially supported with the 11.0 release.  These will again be supported for the 11.1 release.

Installation is simple.  Once you extract the contents of the downloaded tarball (or accessing the redist contents of a DVD/image directory or media), you should simply invoke the "install.sh" script provided.  The user is instructed to accept a EULA, but there is no run-time license enforcement or any other software licensing included in the redist packages.  An uninstall script is produced during the redist install process, which provided for removal of the contents.

A note of caution: if the redist packages are installed on top of an existing Compiler Professional 11.1 package of the same "iteration" (e.g. 11.1.038), it will land on and replace existing files in that compiler installation by default.  Similarly, if the redist uninstall operation is run and the redist and compiler packages are sharing the same directory space, removing the redist package will break the compiler installation.  Since the redist packages are not intended for use by compiler users on their development machines, this should not be an issue in most environments.  But it is mentioned here in case situations come up where this might explain problems that have occurred.

 

Uninstall Instructions

As mentioned above, a standard uninstall script is included with each product installation, regardless of whether the install was performed using menu installs, RPM command line installs, or "silent" installs.  In all cases, using the provided uninstall script should work and is the usual preferred method of removing installed product..  There is one uninstall feature, however, that is undocumented and can be used to make life a little easier.  Here's an example invocation of that feature:

prompt> /opt/intel/Compiler/11.1/038/bin/ia32/uninstall_cproc.sh --default

This "--default" ( dash dash default ) option tells the uninstall script to use the "remove all" option and remove any Compiler Professional components associated with the specific package (in this case all 11.1.023 components, including C/C++, Fortran, IDB, MKL, TBB, and IPP, if installed).  There is no uninstall program interaction when this switch is used.

 

 

Links of Interest

The following links are provided for reference information.

Excellent on-line resource for understanding RPMs and their usage.

Industry organization supporting standardization of Linux operating systems and applications.

]]> http://software.intel.com/en-us/articles/intel-compilers-for-linux-version-111-silent-installation-guide Mon, 29 Jun 2009 13:03:02 -0700 http://software.intel.com/en-us/articles/intel-compilers-for-linux-version-111-silent-installation-guide#comments http://software.intel.com/en-us/articles/intel-compilers-for-linux-version-111-silent-installation-guide Intel® Compilers Intel® C++ Compiler for Linux* Knowledge Base Intel® Fortran Compiler for Linux* Knowledge Base