I have compiled mpich 3.2 with gcc 4.8.3 on centos. Everything seems to be fine. Then I wrote a simple test program,
#include "mpi.h"
int main(int argc,char **argv)
{}
and use the mpic++ to compile. Then errors return,
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memcpy'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to__intel_sse2_strncmp'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memset'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to__intel_sse2_strlen'
What exactly goes wrong? I'm so confused that the error seems to be related with intel compilers, but I use gcc to compile mpich by the command,
./configure --prefix=/home/setups/mpich-3.2/build/ CC=gcc CXX=gcc F77=gfortran FC=gfortran
I have added /home/setups/mpich-3.2/build/bin to PATH and /home/setups/mpich-3.2/build/lib to LD_LIBRARY_PATH
mpicc -v shows：
mpicc for MPICH version 3.2
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/setups/gcc-4.8.3/build/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/setups/gcc-4.8.3/build --with-gmp=/home/setups/gmp-6.1.2/build --with-mpfr=/home/setups/mpfr-3.1.5/build --with-mpc=/home/setups/mpc-1.0.3/build --disable-multilib
Thread model: posix
gcc version 4.8.3 (GCC)
You might find your solution at the open-mpi.org site and their faq for building MPI. For example, item 17.
A common mistake when building Open MPI with the Intel compiler suite
is to accidentally specify the Intel C compiler as the C++ compiler.
Specifically, recent versions of the Intel compiler renamed the C++
compiler "icpc" (it used to be "icc", the same as the C compiler).
Users accustomed to the old name tend to specify "icc" as the C++
compiler, which will then cause a failure late in the Open MPI build
process because a C++ code will be compiled with the C compiler. Bad
Things then happen. The solution is to be sure to specify that the C++
compiler is "icpc", not "icc". For example:
https://www.open-mpi.org/faq/?category=building
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memcpy'
This strongly suggests an Intel compiler was used to build mpich.
That can happen is gcc/g++/gfortran is not in your PATH or if your environment points to the Intel compiler (e.g. CC=icc or CXX=icpc or FC=ifort).
Related
I am trying to build cmake source, which requires C++11.
The build halts and apparently the complaint is that C++11 is not detected. The g++ mode is actually set to -std=gnu++17
This is part of the console log
---------------------------------------------
CMake 3.18.20200919, Copyright 2000-2020 Kitware, Inc. and Contributors
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++ -std=gnu++17
Makefile processor on this system is: make
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
g++ has <ext/stdio_filebuf.h>
---------------------------------------------
g++ -std=gnu++17 -DCMAKE_BOOTSTRAP -DCMake_HAVE_CXX_MAKE_UNIQUE=1 -c $HOME/Apps/CMake-master/Source/cmAddCustomCommandCommand.cxx -o cmAddCustomCommandCommand.o
This is part of the error in the log file...
In file included from /usr/include/c++/5/unordered_map:35:0,
from cmake_bootstrap_11920_test.cxx:4:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
^
cmake_bootstrap_11920_test.cxx:7:2: error: #error "Compiler is not in a mode aware of C++11."
#error "Compiler is not in a mode aware of C++11."
^
cmake_bootstrap_11920_test.cxx:70:16: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
int Member = 1;
Looking around on the web, I noticed that C++11 is only available after gcc version 4.6.
I checked my version, and it seems to be above.
g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
I understand the -std=c++11 flag is used to enable the C++11 features in g++, but I don't seem to know what I am doing in this case.
I tried editing the CompileFlags.cmake file, but no change occurs.
I came upon this page which points to the cmake source I am using.
It says...
bootstrap: Require compiler mode aware of C++11
Some compilers have enough features enabled in their default modes to
pass our simple C++11 unique_ptr check but do not enable enough to build
CMake. Poison this case so that we choose one of the explicit `-std=`
options for such compilers.
Not sure what that means exactly.
How exactly do I change the g++ mode, to C++11, so that on running the bootstrap command, C++11 is used?
Or, in other words, how do I change std to point to C++11 (-std=c++11)?
First of all, you have g++ version 5.4.0 in your host PC installed, which is good, cause it means this is also supports the C++11, which you want to use.
To set it up, you could define it in your CMakeList.txt file:
set (CMAKE_CXX_STANDARD 11)
that should do the trick.
Please also check the documentation:
https://cmake.org/cmake/help/v3.1/variable/CMAKE_CXX_STANDARD.html
Usually, I would suggest to use the latest standard that you compiler is supporting (https://gcc.gnu.org/projects/cxx-status.html), cause you'll get also the latest features introduced in that standard. Exception for this rather in case you are working with legacy codes.
I'm using the Windows version of Clang (LLVM) 8 under Windows.
I'm compiling a code which uses OpenMP.
Under the lib folder of Clang there are 2 files which are OpenMP related:
libomp.lib.
libiomp5md.dll.
My questions are:
When I compile the code I use the flags -Xclang -fopenmp for the compiler. In in GCC and ICC using the flags tell the compiler to link the OpenMP library automatically. What about Clang? Does it do it automatically or must I link with libomp.lib manually? Is there a way to trigger automatic linking to the OpenMP library?
Answer: This was answered in Michael Klemm's answer below - Use the clang driver both for compiling and linking and then the -fopenmp will work as in GCC.
When I link with libomp.lib manually (Defining as a library for the linker) the output exe requires libomp.dll while the supplied OpenMP Dynamic Library is libiomp5md.dll. Is that a bug or is it because I link manually?
Answer: The libomp.dll is supplied in the bin folder and not the lib folder.
What's the proper way to utilize OpenMP in Clang under Windows? The clang-cl driver doesn't work with /openmp or -openmp as the MSVC's cl compiler.
Answer: Currently it can be done either with clang -fopenmp ..., clang-cl -Xclang -fopenmp ... or clang-cl /clang:-fopenmp ... (Which is equivalent of -Xclang -fopenmp).
Remark
On Windows I use Windows Driver of Clang using clang-cl.
Adding clarity to what the OpenMP libraries actually are, and how to use them on Windows with clang-cl
libomp.dll and libiomp5md.dll ARE THE SAME FILES!
When compiling for Windows, you link against libomp.lib OR libiomp5md.lib which will link to the same-named DLL at runtime, i.e. libomp.dll OR libiomp5md.dll respectively.
If you load 2 files that use the "different-name DLL," the interpreter will crash and give you a nasty error like: OMP: Error #15: Initializing libiomp5md.dll, but found libomp.dll already initialized.
Why? Because the program has no idea they are the same DLL, they have different names, so it assumes they are different. And it crashes. For this reason only, you can choose to swap which OpenMP DLL you link to in your program.
If your program doesn't crash and give you an error, you can keep using the same link to OpenMP. Otherwise, to silence the error, link to the one that is loaded by another program already.
If using clang-cl.exe which is the "drop-in" Clang replacement for MSVC cl.exe you should pass a compiler argument such as -Xclang -fopenmp which will convert the argument over to "Clang language." Don't forget to still pass to the linker the OpenMP LIB you chose, because on Windows, it won't be automatic.
That's all I've learned as brief as possible about OpenMP linking on Windows.
To compile and link OpenMP code with clang on Windows, you will have to pass -fopenmp to both the compiler and the linker:
clang -fopenmp -o bla.obj -c bla.c
clang -fopenmp -o bla.exe bla.obj
I am trying to install cmake on solaris machine by building its source code. In one of the steps we need to do "make" to build the source code. When I do a make I am getting below error
/json_reader.cpp:35:18: error: ‘snprintf’ is not a member of ‘std’
#define snprintf std::snprintf
This indicates that code is using c++11 std but gcc compiler uses c++98 std. I have gcc version 4.8.2 (GCC) in the solaris machine. As per my knowledge make is wrapper over gcc.
Question is: How to set CFLAGS for gcc globally so that when I do a "make" it directly uses c++ 11 std.
I'm using the nightly Rust through rustup. I'm trying to build a Windows dll for GNU Octave. Is it possible to use the libstdc++.a from Octave?
I'm able to compile, but linking fails with errors like:
C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib/libstdc++.a(locale.o):(.text$_ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEy+0x2c): undefined reference to `pthread_mutex_lock'
C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib/libstdc++.a(locale.o):(.text$_ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEy+0xa7): undefined reference to `pthread_mutex_unlock'
C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib/libstdc++.a(locale.o):(.text$_ZNSt6locale5_Impl16_M_install_cacheEPKNS_5facetEy+0xde): undefined reference to `pthread_mutex_init'
My current hunch is that the libstdc++.a that is found isn't compatible. It is finding the one from Rust with this order of search paths:
"-L"
"C:\Users\camer\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib"
"-L" "C:\Octave\Octave-4.2.1\lib64\gcc\x86_64-w64-mingw32\4.9.4"
The gcc that ships with Octave 4.2.1 is GCC 4.9.4 released [2016-08-03]. Rust nightly has GCC 6.3 released [2016-12-21]. Do I need to do something like compile the Rust standard library with the GCC 4.9.4 from Octave? Is that possible? Full code and more details in this issue.
I have been trying to use gcc (trunk version) offloading but so far I am failing to do so. I compiled gcc following the instructions for OpenACC offloading with nvidia from this site: https://gcc.gnu.org/wiki/Offloading
I also compiled the host compiler following the instructions of the same website. However, I get an error when I try to compile anything with OpenACC enabled. To make sure I am using the right compiler I cd into the directory of the host compiler and I run this:
./g++ main.cpp -fopenacc -foffload=nvptx-none
But I get this error:
lto-wrapper: fatal error: problem with building target image for nvptx-none
compilation terminated.
/mnt/home/george/usr/local/gcc-7/bin/../lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Running ./g++ -v gives me the following:
Using built-in specs.
COLLECT_GCC=../g++
COLLECT_LTO_WRAPPER=/mnt/home/george/usr/local/gcc-7/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=x86_64-intelmicemul-linux-gnu:nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-7-20161211/configure --prefix=/home/george/usr/local/gcc-7 --disable-multilib --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --enable-offload-targets=x86_64-intelmicemul-linux-gnu=/home/george/usr/local/gcc-7-mic,nvptx-none=/home/george/usr/local/nvptx-tools/nvptx-none --with-cuda-driver=/usr/local/cuda-7.5
Thread model: posix
gcc version 7.0.0 20161211 (experimental) (GCC)`
I would really appreciate If someone could point me to the right direction on what exactly is causing this error.
PS: I have also compiled gcc for Intel mic offloading but I don't care about this for now.
EDIT 1:
When I compile the host compiler, where is the --enable-offload-targets=nvptx-none=XXX should point to? The compiled nvptx or the accel compiler? Also, the nvptx-tools directory includes a bin directory and a nvptx-none\bin directory. Currently I point it to the latter.