-static-intel seems not to work

[Dusan_Z_]

Hello,

I am building an application and trying to link the intel libraries statically in order not to be obliged to send several of them to the customer.

I am trying to use the option -static-intel for the task, but I'm not getting any results.

What I am trying to do is:

ifort mycode.f -static-intel -L/opt/intel/.../em64t -lmkl_lapack -lmkl -lguide -lpthread -O3 -o myapp

but the 'ldd myapp' still returns dynamic dependencies including Intel libraries (along with the system ones).

Am I doing this all wrong? I have such a feeling.

Thanks.

[Kevin_D_Intel]

The option does not apply to Intel MKL libraries only the compiler specific RTLs.

Please show us the complete ldd output and we'll be able to comment on whether the compiler option worked as expected or not.

If the concern is MKL dynamic libraries, then I advise using the outstanding Intel Math Kernel Library Link Line Advisor tool (here) to determine the proper command line options you should use to link static forms of the MKL libraries your program requires.

[Dusan_Z_]

Quoting - Kevin Davis (Intel)

The option does not apply to Intel MKL libraries only the compiler specific RTLs.

Please show us the complete ldd output and we'll be able to comment on whether the compiler option worked as expected or not.

If the concern is MKL dynamic libraries, then I advise using the outstanding Intel Math Kernel Library Link Line Advisor tool (here) to determine the proper command line options you should use to link static forms of the MKL libraries your program requires.

Indeed, it is MKL that I need to link.

Thank you for the advice, I didn't know about the tool you recommended.

Issue closed.

[ethan_mallovesun_com]

Quoting Kevin Davis (Intel)

The option does not apply to Intel MKL libraries only the compiler specific RTLs.

Please show us the complete ldd output and we'll be able to comment on whether the compiler option worked as expected or not.

I'm running into the same problem as the original poster. Here is my ldd output:

$ ldd /opt/SUNWhpc/HPC9.0/intel/bin/64/mpirun
libopen-rte.so.0 => /opt/SUNWhpc/HPC9.0/intel/bin/64/../../lib/64/libopen-rte.so.0 (0x0000002a95557000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003b1f400000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003b24c00000)
libutil.so.1 => /lib64/libutil.so.1 (0x0000003b24200000)
libm.so.6 => /lib64/tls/libm.so.6 (0x0000003b1f200000)
libgcc_s.so.1 => /ws/ompi-tools/gcc-4.0.1/lib64/libgcc_s.so.1 (0x0000002a957bf000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000003b1f800000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000003b1ef00000)
libimf.so => /opt/intel/Compiler/11.0/074/lib/intel64/libimf.so (0x0000002a958cd000)
libsvml.so => /opt/intel/Compiler/11.0/074/lib/intel64/libsvml.so (0x0000002a95c23000)
libintlc.so.5 => /opt/intel/Compiler/11.0/074/lib/intel64/libintlc.so.5 (0x0000002a95de1000)
/lib64/ld-linux-x86-64.so.2 (0x0000003b1eb00000)

I was not expecting libimf.so, libsvml.so, and libintlc.so in my ldd output when using -static-intel.

[Kevin_D_Intel]

Your situation appears to be slightly different than the original poster who compiled/linked using ifort, but your named executable suggests you are building using MPI wrappers, maybe mpif90 or mpif77?

Perhaps the MPI compiler driver used is not passing the static-intel on to the actual ifort compiler.

Can you check that? Does a -#show the actual ifort compiler command-line the MPI driver uses? Is this a MPI configuration that must be chosen when building MPI itself for use with ifort?

[ethan_mallovesun_com]

Quoting Kevin Davis (Intel)

Your situation appears to be slightly different than the original poster who compiled/linked using ifort, but your named executable suggests you are building using MPI wrappers, maybe mpif90 or mpif77?

Perhaps the MPI compiler driver used is not passing the static-intel on to the actual ifort compiler.

Can you check that? Does a -#show the actual ifort compiler command-line the MPI driver uses? Is this a MPI configuration that must be chosen when building MPI itself for use with ifort?

It wasn't compiled with mpicc. The compile line is this:

/bin/sh ../../../libtool --tag=CC --mode=link icc -O3 -DNDEBUG -Wall -static-intel -m64 -finline-functions -fno-strict-aliasing -restrict -fexceptions -pthread -fvisibility=hidden -export-dynamic -fexceptions -o opal_wrapper opal_wrapper.o ../../../opal/libopen-pal.la -lnsl -lutil
libtool: link: icc -O3 -DNDEBUG -Wall -static-intel -m64 -finline-functions -fno-strict-aliasing -restrict -fexceptions -pthread -fvisibility=hidden -fexceptions -o .libs/opal_wrapper opal_wrapper.o -Wl,--export-dynamic ../../../opal/.libs/libopen-pal.so -ldl -lnsl -lutil -pthread -Wl,-rpath -Wl,$ORIGIN -Wl,-rpath -Wl,$ORIGIN/.. -Wl,-rpath -Wl,$ORIGIN/../../lib/64

-# on opal_wrapper shows:

"-mIPOPT_cmdline_link="/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../crt1.o" "/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../crti.o" "/usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/crtbegin.o" "--eh-frame-hdr" "
-dynamic-linker" "/lib/ld-linux.so.2" "-m" "elf_i386" "-o" "a.out" ".libs/opal_wrapper" "-L/opt/intel/Compiler/11.0/074/lib/ia32" "-L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/32" "-L/usr/lib/gcc/x86_64-redhat-linux/3
.4.6/" "-L/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../" "-L/lib/" "-L/usr/lib" "-Bstatic" "-limf" "-lsvml" "-Bdynamic" "-lm" "-Bstatic" "-lipgo" "-ldecimal" "-Bdynamic" "-lgcc_s_32" "-lgcc" "-Bstatic" "-lirc"
"-Bdynamic" "-lc" "-lgcc_s_32" "-lgcc" "-Bstatic" "-lirc_s" "-Bdynamic" "-ldl" "-lc" "/usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/crtend.o" "/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../crtn.o"" \

[Kevin_D_Intel]

I see. So I guess this does not involve Fortran/ifort.

There's evidence in the output of linking the static forms of libimf and libsvml (i.e. "-Bstatic" "-limf" "-lsvml") but not libintlc but I can't determine if that is reflective of the build formpirun.

I suggest you look at producing a link map (see the "ld" Map command) when linking to create mpirun to see what is causing the shared forms to be pulled in.

[ethan_mallovesun_com]

Quoting Kevin Davis (Intel)

I see. So I guess this does not involve Fortran/ifort.

There's evidence in the output of linking the static forms of libimf and libsvml (i.e. "-Bstatic" "-limf" "-lsvml") but not libintlc but I can't determine if that is reflective of the build formpirun.

I suggest you look at producing a link map (see the "ld" Map command) when linking to create mpirun to see what is causing the shared forms to be pulled in.

Sorry, I posted the wrong compile line above. I created a link map using the correct compile line (note: mpirun is a symlink to orterun):

$ icc -DNDEBUG -Wall -static-intel -m64 -fno-strict-aliasing -restrict -fexceptions -pthread -fvisibility=hidden -g -O0 -fexceptions -o .libs/orterun main.o orterun.o debuggers.o -Wl,--export-dynamic ../../../orte/.libs/libopen-rte.so -ldl -lnsl -lutil -pthread -Wl,-rpath -Wl,\$ORIGIN -Wl,-rpath -Wl,\$ORIGIN/.. -Wl,-rpath -Wl,\$ORIGIN/../../lib/64 -Wl,-Map

The link map looks good, as it's pulling in the .a (not the .so):

...
LOAD /opt/intel/Compiler/11.0/074/lib/intel64/libimf.a
LOAD /opt/intel/Compiler/11.0/074/lib/intel64/libsvml.a
...

Interestingly, an ldd from within the build tree doesn't show the libimf.so dependency. Same md5sums:

$ md5sum .libs/orterun /ws/hpc-ct-1/hpc-ct-9.0/pkgs/04a/Linux-rhel4/x86_64/built-with-intel/installs/clustertools-9.0-hg--clustertools-9.0-packages--1.5/install/opt/SUNWhpc/HPC9.0/intel/instrument/bin/64/orterun
312dba560e994f92f1b985afb2b7011a .libs/orterun
312dba560e994f92f1b985afb2b7011a /ws/hpc-ct-1/hpc-ct-9.0/pkgs/04a/Linux-rhel4/x86_64/built-with-intel/installs/clustertools-9.0-hg--clustertools-9.0-packages--1.5/install/opt/SUNWhpc/HPC9.0/intel/instrument/bin/64/orterun

Different ldd output:

$ ldd .libs/orterun /ws/hpc-ct-1/hpc-ct-9.0/pkgs/04a/Linux-rhel4/x86_64/built-with-intel/installs/clustertools-9.0-hg--clustertools-9.0-packages--1.5/install/opt/SUNWhpc/HPC9.0/intel/instrument/bin/64/orterun
.libs/orterun:
libopen-rte.so.0 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x0000003b1f400000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003b24c00000)
libutil.so.1 => /lib64/libutil.so.1 (0x0000003b24200000)
libm.so.6 => /lib64/tls/libm.so.6 (0x0000003b1f200000)
libgcc_s.so.1 => /ws/ompi-tools/gcc-4.0.1/lib64/libgcc_s.so.1 (0x0000002a9558b000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000003b1f800000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000003b1ef00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003b1eb00000)
/ws/hpc-ct-1/hpc-ct-9.0/pkgs/04a/Linux-rhel4/x86_64/built-with-intel/installs/clustertools-9.0-hg--clustertools-9.0-packages--1.5/install/opt/SUNWhpc/HPC9.0/intel/instrument/bin/64/orterun:
libopen-rte.so.0 => /ws/hpc-ct-1/hpc-ct-9.0/pkgs/04a/Linux-rhel4/x86_64/built-with-intel/installs/qTI0/install/opt/SUNWhpc/HPC9.0/intel/instrument/bin/64/../../lib/64/libopen-rte.so.0 (0x0000002a95558000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003b1f400000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003b24c00000)
libutil.so.1 => /lib64/libutil.so.1 (0x0000003b24200000)
libm.so.6 => /lib64/tls/libm.so.6 (0x0000003b1f200000)
libgcc_s.so.1 => /ws/ompi-tools/gcc-4.0.1/lib64/libgcc_s.so.1 (0x0000002a957bf000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000003b1f800000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000003b1ef00000)
libimf.so => /opt/intel/Compiler/11.0/074/lib/intel64/libimf.so (0x0000002a958cd000)
libsvml.so => /opt/intel/Compiler/11.0/074/lib/intel64/libsvml.so (0x0000002a95c23000)
libintlc.so.5 => /opt/intel/Compiler/11.0/074/lib/intel64/libintlc.so.5 (0x0000002a95de1000)
/lib64/ld-linux-x86-64.so.2 (0x0000003b1eb00000)

So now I'm really confused. How can two apparently identical files have different ldd output?

[Kevin_D_Intel]

The ldd for .libs/orterun didn't find libopen-rte.so.0.Perhaps that's a factor.