Intel Software Network articles Feed

FLEXlm license manager 2.0 installer may fail using dash

Fri, 20 Jan 2012 15:00:00 -0800

Installation of the new Intel® License Manager for FLEXlm* version 2.0 for Linux* (released Janaury 2012) may fail with syntax errors when being executed under the dash.

Check the /bin/sh link which shell it actually links to, for example

$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 2010-05-27 16:10 /bin/sh -> dash

If it links to the dash (as shown above) you may solve the issue with one of the following:

Solution 1: Link /bin/sh to bash
(at least for the time of installation; requires (sudo) root rights), for example

# rm /bin/sh
# ln -s /bin/bash /bin/sh

Solution 2: Replace the Shebang line in the install script
Edit file Intel_INSTALL and
replace
#!/bin/sh
by
#!/bin/bash

FLEXlm License Manager 2.0 may fail when LSB 3 is not met

Thu, 12 Jan 2012 15:00:00 -0800

With the new Intel® License Manger for FLEXlm* version 2.0 for Linux* (released January 2012) you may encounter problems due to the lack of Linux Standard Base (LSB) compliance on your system. The Intel License Manager requires LSB compliance version 3 or higher.

More info about LSB support can be found here.

The problems seen are the following:

1) IA32 Systems

Starting the license manager lmgrd issues the error:

   -bash: ./lmgrd: /lib/ld-lsb.so.3: bad ELF interpreter: No such file or directory

Solution: Add LSB support to your operating system. As a quick workaround you may create the LSB linker/loader shared library manually as a symblic link to the Linux dynamic linker/loader shared library, for example (requires (sudo) root rights):

   # ln -s /lib/ld-linux.so.2 /lib/ld-lsb.so.3

2) Intel64® Systems

The product installer Intel_INSTALL issues an error:

   flexlm$ ./Install_INTEL
   *** Error: installed software will not run; package might be for the wrong platform, or corrupted

There may be other reasons causing that error, but one of them may missing LSB support on your system.

Solution: Check your system whether LSB is installed by running
   $ lsb_release
on any shell. If it returns info about LSB packages (core-3*, graphics-3*, desktop-3*, cxx-3* etc.), your system may be LSB 3 compliant. Addationally you could check whether the lsb linker/loader shared library is present on your system, for example:
   $ ls -al /lib64/ | grep linux
   lrwxrwxrwx 1 root root 9 Oct 17 11:07 ld-linux-x86-64.so.2 -> ld-2.5.so

If the LSB linker/loader shared library ls-lsb-x86-64.so.3 is not present, add LSB support to your operating system. As a quick workaround you may create the LSB linker/loader library manually as a symblic link to the Linux dynamic linker/loader library, for example (requires (sudo) root rights):

   # ln -s /lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3

Pardus Linux: Intel Debugger may fail to start

Wed, 04 Jan 2012 15:00:00 -0800

Due to a compatibility problem with the default .gdbinit startup script delivered with Pardus Linux* 2011.2, 64-bit, the Intel® IDB Debugger may fail to start. If the debugger (command line tool 'idbc' or GUI version 'idb') doesn't start correctly, you may add the command line option -nx to bypass the .gdbinit startup script as follows:

Running the debugger GUI:
$ idb -nx

Running the command line debugger:
$ idbc -nx

This is a known limitation with the Intel® IDB Debugger for Linux* as part of the Intel® Composer XE 2011 Update 8 and will be solved with one of the next update releases of the Composer XE.

Different behavior of LAPACK dgelss and dgesvd on Windows* and Linux*

Tue, 07 Jul 2009 11:30:00 -0700

The LAPACK least squares function dgelss gives a different results on Linux* compared with Windows*. Though, it is difficult to get a bit-to-bit correspondence values on both systems, but considering the following may help to get consistent results.

Align the arrays to 16 bytes boundary.
Use 80-bit precision instead of the default 64-bit on IA32, which is used on the Intel® compiler. This can be set by using /Qpc80 compiler flag on Windows.

For a rank-deficient matrix, it is not easy to get deterministic results. For a rank 2 matrix, only 2 singular vectors will be computed to the working precision and other singular vectors could be any vectors that complement the orthonormal system along the first two, because SVD algorithm becomes unstable in the range of very small singular values. It is unavoidable and we can guarantee bit-to-bit correspondence of the results only on the systems with absolutely the same architecture, same MKL version, same arrays alignment, same FP units flags (precision, rounding etc), running in the same number of threads. Otherwise, ill-conditioned problems cause the different results from the practical point of view, in case of SVD returns several singular values equal to zero (to the working precision). The following should be considered to avoid the different behaviours.

Least square problems still should be solved in deterministic way, because the algorithm doesn't use "bad" singular vectors corresponding to zero singular values to compute the solution.
If user needs a deterministic full set of singular vectors, not only for non-zero singular values, user may rebuild "bad" vectors using one of the deterministic procedures making orthonormal vectors to some initial orthonormal subset of "good" vectors. At any rate, user has to examine the singular values to understand whether the singular vectors are meaningful or not.
Using 80-bit precision which doesn't mean that user doesn't take advantage of SIMD instructions - it means that internal FPU computations will be taken using 80-bit precision. On IA32, MKL has both vectorized and non-vectorized x87 code. Most performance relies on the vectorized code and setting 80-bit FPU precision doesn't hurt vectorized code at all. Neither 80-bit precision flag affects the x87 code performance, but makes x87 code more accurate. On Windows user could set it by compiling main program with /Qpc80 flag using Intel compiler.

Intel® MKL Does Not Immediately Release Memory

Thu, 20 Nov 2008 10:30:00 -0800

In order to achieve better performance, memory allocated by Intel® MKL is not released. This behavior is by design and is a one-time occurrence for Intel MKL routines that require workspace memory buffers. Even so, the user should be aware that some tools might report this as a memory leak. Should the user wish, memory can be released by the user program through use of a function made available in Intel MKL or memory can be released after each call by setting an environment variable (see technical user notes in the doc directory for more details).

Using one of these methods to release memory will not necessarily stop programs from reporting memory leaks, and in fact may increase the number of such reports should you make multiple calls to the library thereby requiring new allocations with each call. Memory not released by one of the methods described will be released by the system when the program ends.