Statically linking Intel MP Linpack on Linux: multiple definition of symbols 'free' and 'realloc'

[Grigory_R_Intel]

Hello!

I am trying to compile Intel MP Linpack from source code with some external libraries on Linux x86_64 (Debian 5.0.8). I use recent MKL set, latest Intel MPI library and latest Intel Compiler. In order to work properly the final binary should be made static (I want some flavour of PIN-based tool to be incorporated into the binary)

I am currently encountering the following problem at final linking:

mpiicc -DAdd__ -DF77_INTEGER=int -DStringSunStyle -DASYOUGO -DHYBRID -I/home/user/linpack_10.3.3/benchmarks/mp_linpack/include -I/home/user/linpack_10.3.3/benchmarks/mp_linpack/include/intel64 -I/opt/intel/composerxe-2011.3.174/mkl/include -I/opt/intel/impi/4.0.1.007/include64 -I/opt/intel/composerxe-2011.3.174/mkl/include -O3 -w -ansi-alias -i-static -z noexecstack -openmp -nocompchk -openmp -mt_mpi -i-static -z noexecstack -static_mpi -nocompchk -u CarbonStartSim -u CarbonStopSim -L/home/user/mit-carbon-Graphite-52bf5d5/lib -L/home/user/mit-carbon-Graphite-52bf5d5/os-services-25032-gcc.4.0.0-linux-ia32_intel64/intel64 -L/home/user/mit-carbon-Graphite-52bf5d5/contrib/orion -pthread -lcarbon_sim -lorion -los-services -lboost_filesystem-mt -lboost_system-mt -pthread -lstdc++ -lm -static -o /home/user/linpack_10.3.3/benchmarks/mp_linpack/bin/intel64/xhpl HPL_pddriver.o HPL_pdinfo.o HPL_pdtest.o /home/user/linpack_10.3.3/benchmarks/mp_linpack/lib/intel64/libhpl.a -L/opt/intel/composerxe-2011.3.174/mkl/lib/intel64 /opt/intel/composerxe-2011.3.174/mkl/lib/intel64/libmkl_intel_lp64.a /opt/intel/composerxe-2011.3.174/mkl/lib/intel64/libmkl_intel_thread.a /opt/intel/composerxe-2011.3.174/mkl/lib/intel64/libmkl_core.a -lpthread /home/user/linpack_10.3.3/benchmarks/mp_linpack/lib_hybrid/intel64/libhpl_hybrid.a /opt/intel/composerxe-2011.3.174/compiler/lib/intel64/libiomp5.a

/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib64/libc.a(malloc.o): In function `free':

(.text+0x2700): multiple definition of `free'

/opt/intel/impi/4.0.1.007/intel64/lib/libmpi_mt.a(i_rtc_hook.o):../../i_rtc_hook.c:(.text+0x0): first defined here

/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib64/libc.a(malloc.o): In function `realloc':

(.text+0x4b10): multiple definition of `realloc'

/opt/intel/impi/4.0.1.007/intel64/lib/libmpi_mt.a(i_rtc_hook.o):../../i_rtc_hook.c:(.text+0x120): first defined here

/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib64/libc.a(malloc.o): In function `free':

(.text+0x2700): multiple definition of `free'

/opt/intel/impi/4.0.1.007/intel64/lib/libmpi_mt.a(i_rtc_hook.o):../../i_rtc_hook.c:(.text+0x0): first defined here

/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib64/libc.a(malloc.o): In function `realloc':

(.text+0x4b10): multiple definition of `realloc'

/opt/intel/impi/4.0.1.007/intel64/lib/libmpi_mt.a(i_rtc_hook.o):../../i_rtc_hook.c:(.text+0x120): first defined here

For some unknown reason Intel MPI has two symbols defined in stock Libc and that breaks linking.

When I remove '-static' flag from linker options everything links fine but I get a binary with shared libs which is not what I need (as instrumentation I am attempting to use is not designed to work with code from shared libraries)

Could anyone tell me how to overcome this problem with symbols?

Thank you!

[TimP]

Would it not be safer to link libpthread normally (once, at the end, as already set by the -openmp option, so as to follow all libraries creating dependencies)? You can get away with odd linking orders more often with dynamic libraries. I suppose it should not be a problem to link against libiomp5.a and then libiomp5.so, provided that libpthread is searched afterwards only.

[Grigory_R_Intel]

It seems that adding '--allow-multiple-definition' to linker flags (as the first one - the order is important!) resolved the linking issue. See also Release Notes:

- (SDK only) Certain versions of the GNU* LIBC library define

free()/realloc() symbols as non-weak. Use the --allow-multiple-definition

GNU* linker option to link your application.

I also have been advised that complete static linking of Intel MKL is a bad idea. But at least it is possible to do.

--allow-multiple-definitionTo Subject Sent Size Categories
Derbunovich, Andrey; Kuzmin, Dmitry RE: multiple definition of symbols 'free' and 'realloc' 13:05 23 KB Red Category

[Dmitry_K_Intel2]

The only thing I'd like to add here is a suggestion to use MKL Link advisor.