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'

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
4 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

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.

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

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

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen