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

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

Imagen de Grigory Rechistov (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!

-- Best regards, Grigory Rechistov
publicaciones de 4 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Tim Prince

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.

Imagen de Grigory Rechistov (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
-- Best regards, Grigory Rechistov
Imagen de Dmitry Kuzmin (Intel)

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

Inicie sesión para dejar un comentario.