(repost)TLS definition in libmpi_mt.so section .tbss mismatches non-TLS definition in libmpi.so.12 section .bss

[psing51]

Please see this post for the problem that i am facing while compiling NAMD for mic.
i am using  icc version (on centos 6.5 machine with mic) 15.0.0. for namd source compilation and i get :

icpc: warning #10193: -vec is default; use -x and -ax to configure vectorization
ld: MPIR_Thread: TLS definition in /opt/intel//impi/5.0.1.035/intel64/lib/release_mt/libmpi_mt.so section .tbss mismatches non-TLS definition in /opt/intel//impi/5.0.1.035/intel64/lib/libmpi.so.12 section .bss
/opt/intel//impi/5.0.1.035/intel64/lib/libmpi.so.12: could not read symbols: Bad value

For some reasons i have to stick with 15.0.0 compiler, but i  gave a try on virtual machine with intel 2015 v3 and  no such errors are reported (intel compiler 15.0.3) as namd2 binary gets generated. So i wish to know weather is it a compiler bug of there are some issues with the compiler flags/build procedure that i am using . I came across article  and i guess update 3 was not out at that time. 

So i wish to know what flags / build steps need to be corrected so that i am able to compile namd with 15.0.0 compiler (namd_build_smp.sh_.txt).

eagerly awaiting your replies,



 

[Kevin_D_Intel]

In reviewing various posts/articles it seems the resolution of this error involved ensuring consistent use of related options responsible for linking in the appropriate MPI libraries and that nothing really specific seem related to the compiler itself. I’m not sure how your case may differ.

Do your 15.0.0 and 15.0.3 systems have the identical MPI and other software installed?

It is possible to install the PSXE 2015 product updates side-by-side without impacting each other. I don’t know whether you might consider installing 15.0.3 on your 15.0.0 system to see whether you can replicate the success on that system also. That might be an better suited setup to help identify the root cause of the different behavior.

Before installing 15.0.3, as per this thread, it is suggested you may need to add -mt_mpi to all compilation/link commands to ensure consist use of the appropriate MPI libraries. I see -qopenmp in your namedmic.log (from your other post) and your namd_build_smp.sh_.txt posted here but not -mt_mpi. To quote James in his initial reply in the thread I cited, "If you are using one of the flags [ -mt_mpi, -openmp, -parallel, -threads, -reentrancy, or -reentrancy threaded ] other than -mt_mpi and want to restrict it to only the necessary routines, then adding -mt_mpi to others should be sufficient."

Another related instance of this error and resolution is discussed in this thread.

I'm hoping this might help.

[TimP]

My understanding of -mt_mpi is that it will be required if you call MPI inside a threaded parallel region; otherwise not.  As others suggested, your error message seems to indicate you are trying to link against both that library and the default one, so if you need mt_mpi, you should use that option throughout.

[psing51]

Thankyou very much for your replies ; the -mt_mpi was not needed in my case ;
I inspected the compilation procedure and found that some default flags were being picked up from file arch/Linux-x86_64.mic , which i guess is for code pertaining to mic offload! (-openmp)

mpiicpc  -I.rootdir/./charm-6.6.1/mpi-linux-x86_64-ifort-smp-mpicxx/include -DCMK_OPTIMIZE=1 -Isrc -Iinc    -Iplugins/include -DSTATIC_PLUGIN -I/home/puneet/NAMD_BUILD/common_dependencies/include -DNAMD_TCL -I/home/puneet/NAMD_BUILD/common_dependencies/include -DNAMD_FFTW  -DNAMD_MIC   -DNAMD_VERSION=\"2.10\" -DNAMD_PLATFORM=\"Linux-x86_64-MPI-smp-MIC\"  -DREMOVE_PROXYRESULTMSG_EXTRACOPY -DNODEAWARE_PROXY_SPANNINGTREE -DUSE_NODEPATCHMGR    -O2 -qopenmp  -offload-option,mic,compiler,-vec -offload-option,mic,compiler,-restrict -openmp -o obj/buildinfo.o -c obj/buildinfo.C

now in the same file there is a variable that decides those flags,& there i simply changed -openmp to -qopenmp as:

CXXMICOPTS= -offload-option,mic,compiler,-vec -offload-option,mic,compiler,-restrict -qopenmp" arch/Linux-x86_64.mic

and the following is also reflected in the build procedure:-

mpiicpc  -I.rootdir/./charm-6.6.1/mpi-linux-x86_64-ifort-smp-mpicxx/include -DCMK_OPTIMIZE=1 -Isrc -Iinc    -Iplugins/include -DSTATIC_PLUGIN -I/home/puneet/NAMD_BUILD/common_dependencies/include -DNAMD_TCL -I/home/puneet/NAMD_BUILD/common_dependencies/include -DNAMD_FFTW  -DNAMD_MIC   -DNAMD_VERSION=\"2.10\" -DNAMD_PLATFORM=\"Linux-x86_64-MPI-smp-MIC\"  -DREMOVE_PROXYRESULTMSG_EXTRACOPY -DNODEAWARE_PROXY_SPANNINGTREE -DUSE_NODEPATCHMGR    -O2 -qopenmp  -offload-option,mic,compiler,-vec -offload-option,mic,compiler,-restrict -qopenmp -o obj/buildinfo.o -c obj/buildinfo.C

and this solved my problem.

[Kevin_D_Intel]

I am glad to hear the problem is resolved; however, it is puzzling how that change may have contributed to resolving this. The, -qopenmp spelling is equivalent to -openmp.

While you note -openmp is found in what may be a build file specific to the Xeon Phi™, with the lack of double-quotes the option is not passed to the target compilation (i.e. Xeon Phi™) along with the -restrict that precedes it; thus, it applies to the host compilation and changing -qopenmp simply duplicates -qopenmp that already appears in the command-line just after the -O2 option. It seems unlikely this change might have resolved the issue.

If you happened to do a complete clean and then a build after this change then maybe some incompatible binaries leading to the link error may have been removed and rebuilt with consistent options leading to the success.

Anyway, glad you seem to have resolved the issue.

[Gert_Lindner]

found this post today - I try to compile hpl , in pdtest got an mismatch

mpchk -Wall  ../HPL_pdtest.c

mpiicc -DAdd__ -DF77_INTEGER=int -DStringSunStyle -DHPL_DETAILED_TIMING -DHPL_PROGRESS_REPORT -I/home/lindne03/hpl/include -I/home/lindne03/hpl/include/Linux_Intel64 -I/cluster/intel/compilers_and_libraries_2017.1.132/linux/mkl/mkl/include -I/cluster/intel/impi/4.1.3.048/include64 -O3 -w -ansi-alias -i-static -z noexecstack -z relro -z now -nocompchk -Wall -openmp  -o /home/lindne03/hpl/bin/Linux_Intel64/xhpl HPL_pddriver.o         HPL_pdinfo.o           HPL_pdtest.o /home/lindne03/hpl/lib/Linux_Intel64/libhpl.a  -L/cluster/intel/compilers_and_libraries_2017.1.132/linux/mkl/mkl/lib/intel64 -Wl,--start-group /cluster/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64/libmkl_intel_lp64.a /cluster/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64/libmkl_intel_thread.a /cluster/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64/libmkl_core.a -Wl,--end-group -lpthread -ldl /cluster/intel/impi/4.1.3.048/lib64/libmpi.a

ld: MPIR_Thread: TLS definition in /cluster/intel/impi/4.1.3.048/intel64/lib/libmpi_mt.so section .tbss mismatches non-TLS definition in /cluster/intel/impi/4.1.3.048/lib64/libmpi.a(initthread.o) section .bss

mpiicpc -show

icpc -I/cluster/intel/impi/4.1.3.048/intel64/include -L/cluster/intel/impi/4.1.3.048/intel64/lib -Xlinker --enable-new-dtags -Xlinker -rpath -Xlinker /cluster/intel/impi/4.1.3.048/intel64/lib -Xlinker -rpath -Xlinker /opt/intel/mpi-rt/4.1 -lmpigc4 -lmpigf -lmpi -lmpigi -ldl -lrt -lpthread

# LINKFLAGS    = $(CCFLAGS) $(OMP_DEFS) -mt_mpi

modiefied to  LINKFLAGS    = $(CCFLAGS) $(OMP_DEFS)

should adjust "both sides" TLS / non-TLS but didn't found the other side ..

Regards

Gert