Debian packages and Intel Compilers

Intel distributes their Linux compilers (Fortran and C/C++) using the RPM format for use on Redhat and Suse systems. However, their compilers work fine with Debian (assuming the correct libraries are installed). Don't install RPM on your deb system, it's not necessary

The alien program can convert rpms to deb format, and is trivial to use. This is all you need to install the compilers on Debian, but then you need to make some post-installation modifications that the Intel installation script does. We can modify the deb packages to make these post-installation modifications for us. By doing so it's even easier to than using Intel's install scripts on the original rpms.

Below are the steps. This works for the ifc/ifort, icc and iidb packages. I haven't tried the icc-ide package yet, as I don't use an IDE. Note that alien will increment the version number of a package unless you give it the -k argument.

Version 7.1 to 10.0 compilers

Download the script. It uses bash, which you might need to install.

1. Convert the rpm package to deb format. alien -k intel-ifc7-7.1-41.i386.rpm
2. Run the script. ./fix_deb intel-ifc7_7.1-41_i386.deb
3. Install the package. dpkg -i intel-ifc7_7.1-41_i386.deb

The Proper Way...

1. Use rpmrebuild to fix the rpms. Do it on an rpm based distribution. Get the details . Better yet, lobby Intel to fix them in the first place.

2. Run alien >= 8.65 on the rpm.

Math Kernel Library 10.0

They've got this right. The only annoying thing now is that the rpm is not distributed as an rpm, but part of a self extracting shell script. Use alien >= 8.65 to get it to correctly convert the post-install scripts in the rpm.

1. Install the licence file, which the install script checks for. mkdir -p /opt/intel/licenses cp mylicensefile.lic /opt/intel/licenses
2. Extract the rpm from the install script. l_mkl_p_10.0.011/install/install --extract .
3. Convert the rpm package to deb format. alien -k --scripts intel-mkl100023-10.0p-023.noarch.rpm
4. Install the package. dpkg -i intel-mkl100023_10.0p-023_all.deb

Notes

• For converting em64t versions, make sure you have the ia32-libs package installed, and alien >= 8.61.

• Make sure you "source" the iccvars.csh, ifortvars.csh and/or idbvars.csh files in tcsh before trying to use the compilers or other utilities. There are bash versions too. They are all in the bin directories.

• If you get problems sourcing iccvars.sh/ifortvars.sh and your /bin/sh isn't a symlink to /bin/bash, then edit iccvars.sh/ifortvars.sh and change the #!/bin/sh to #!/bin/bash. Don't blame the Ubuntu developers or Dash, blame Intel for assuming sh is bash. (the export command in dash does not have a -n flag, while in bash it does).

• If you get strange errors with icpc 8.1 and have G++ 3.3.4 installed, try "ln -s /usr/include/c++/3.3 /usr/include/c++/3.3.4". If this works, the problem is a bug in the Intel compiler; it should ask G++ where it is located rather than assume something.

• If you want to submit bug reports to Intel, you might need the package id (I usually just give them the build number). The package id is normally shown by invoking the compiler with the -V flag. The package id is just stored in a file, and the scripts above don't fix this yet, and instead the -V flag prints out "installpackageid". The package id is something like l_fc_pc_8.1.024 or l_cc_8.1.028. If you really want, you can put it in the file yourself. Look for the file "csupport" or "fsupport" or "idbsupport" in the appropriate Intel doc directory.

• If you get a filename conflict for uninstall.sh when installing packages, just add --force-overwrite to the dpkg command line.

• While compiling with the Intel C compiler on AMD64, I received the error message:

  Catastrophic error: could not set locale "" to allow
  processing of multibyte characters.

  Setting the environment variable LANG=C seemed to fix this.

• If iidb complains about a missing libXft.so.1 (it will on Etch), there is a dodgy workaround from .

Legacy Stuff Version 9.x compilers on AMD64 with Alien < 8.61

This section is just for historical reasons (i.e. so I don't forget). Just get a new version of Alien.

Intel likes to call the architecture em64t instead of amd64 in their rpms. If you have alien 8.61 or later this will not be a problem, as em64t is an alias for amd64. Thanks go to Joey Hess (the Alien maintainer) for putting this in for us.

If you don't have a recent version of alien, the process is in principle the same as above, but gets ugly with a workaround.

1. Extract the contents of the rpm. For the below package it puts them into the subdirectory intel-iforte9-9.0. alien -gsk intel-iforte9-9.0-031.em64t.rpm
2. Fix some broken directory access permissions from the above extraction. (This is because these parent directories are not listed separately in the rpm, so alien creates them but with root-only permissions). chmod a+rx intel-iforte9-9.0/opt intel-iforte9-9.0/opt/intel
   intel-iforte9-9.0/opt/intel/fce intel-iforte9-9.0/opt/intel/fce/9.0
3. edit intel-iforte9-9.0/debian/control, change the Architecture from em64t to amd64: Architecture: amd64
4. Build the package. cd intel-iforte9-9.0
   debian/rules binary

   Ignore the libstdc++ dependency warnings. The package is now built and installable, but doesn't have the post-install fixes yet.

5. Run the fix_deb script as above.

   ./fix_deb intel-iforte9_9.0-031_amd64.deb

6. Install the package.

   dpkg -i intel-iforte9_9.0-031_amd64.deb

Acknowledgements

A double thanks to Joey Hess. First for getting Alien 8.61 to recognise em64t as amd64. Secondly, for getting Alien 8.65 to set RPM_INSTALL_PREFIX in the post-install of converted rpms.

Author

Daniel Grimwood
[e-mail]

Comments appreciated.