The OpenMP website says: "GCC 4.9 supports OpenMP 4.0 for C/C++".
I'm using gcc 4.9.1 from brew, yet I see this error when I try to compile liblinear: omp.h file not found.
Specifically:
Compiling liblinear version 1.93
Source code page:
http://www.csie.ntu.edu.tw/~cjlin/liblinear/
external/liblinear-1.93_multicore/matlab/train.cpp:7:10: fatal error: 'omp.h' file not found
#include <omp.h>
^
1 error generated.
mex: compile of ' "external/liblinear-1.93_multicore/matlab/train.cpp"' failed.
Here's the matlab code used to compile liblinear, which contains a file that contains #include <omp.h>:
% Compile liblinear
if ~exist('liblinear_train')
fprintf('Compiling liblinear version 1.93\n');
fprintf('Source code page:\n');
fprintf(' http://www.csie.ntu.edu.tw/~cjlin/liblinear/\n');
mex -outdir bin ...
COMPFLAGS="$COMPFLAGS -fopenmp" -largeArrayDims ...
external/liblinear-1.93_multicore/matlab/train.cpp ...
external/liblinear-1.93_multicore/matlab/linear_model_matlab.cpp ...
external/liblinear-1.93_multicore/linear.cpp ...
external/liblinear-1.93_multicore/tron.cpp ...
"external/liblinear-1.93_multicore/blas/*.c" ...
-output liblinear_train;
end`
UPDATE
I changed the gcc version in mexopts.sh (side note: I copied it from /Applications/MATLAB_R2013a_Student.app/bin/mexopts.sh to ~/.matlab/R2013a). Specifically, I changed CC=xcrun -sdk macosx10.9 clang to CC='gcc-4.9'.
I think Matlab does indeed use this compiler, because when I run this code:
if ~exist('anigauss')
fprintf('Compiling the anisotropic gauss filtering of:\n');
fprintf(' J. Geusebroek, A. Smeulders, and J. van de Weijer\n');
fprintf(' Fast anisotropic gauss filtering\n');
fprintf(' IEEE Transactions on Image Processing, 2003\n');
fprintf('Source code/Project page:\n');
fprintf(' http://staff.science.uva.nl/~mark/downloads.html#anigauss\n\n');
mex -Dchar16_t=uint16_T -outdir bin ...
selective_search/SelectiveSearchCodeIJCV/Dependencies/anigaussm/anigauss_mex.c ...
selective_search/SelectiveSearchCodeIJCV/Dependencies/anigaussm/anigauss.c ...
-output anigauss
end
Matlab prints:
dyld: Library not loaded: /usr/local/opt/mpfr2/lib/libmpfr.1.dylib
Referenced from: /usr/local/Cellar/gcc49/4.9.1/libexec/gcc/x86_64-apple-darwin14.0.0/4.9.1/cc1
Reason: Incompatible library version: cc1 requires version 4.0.0 or later, but libmpfr.1.dylib provides version 3.0.0
gcc-4.9: internal compiler error: Trace/BPT trap: 5 (program cc1)
/Applications/MATLAB_R2013a_Student.app/bin/mex: line 1343: 77128 Abort trap: 6 gcc-4.9 -c -I/Applications/MATLAB_R2013a_Student.app/extern/include -I/Applications/MATLAB_R2013a_Student.app/simulink/include -DMATLAB_MEX_FILE -fno-common -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -mmacosx-version-min=10.9 -fexceptions -Dchar16_t=uint16_T -DMX_COMPAT_32 -O2 -DNDEBUG "selective_search/SelectiveSearchCodeIJCV/Dependencies/anigaussm/anigauss_mex.c" -o bin/anigauss_mex.o
mex: compile of ' "selective_search/SelectiveSearchCodeIJCV/Dependencies/anigaussm/anigauss_mex.c"' failed.
Yet when I try to compile liblinear, I get the very same error message as usual.
COMPFLAGS="$COMPFLAGS /openmp" -largeArrayDims ...
^^^^^^^
This was probably written for Microsoft Visual C/C++ or for Intel C/C++ Compiler on Windows. Unix systems, including OS X, traditionally use - to denote command line flags.
To enable OpenMP support in GCC you should change /openmp to -fopenmp in the compiler flags COMPFLAGS.
It appears that in addition to passing the wrong OpenMP flag, mex is using the wrong compiler. Compare the error outputs from GCC and Clang:
GCC
foo.c:1:25: fatal error: nonexistent.h: No such file or directory
#include <nonexistent.h>
^
compilation terminated.
Clang
foo.c:1:10: fatal error: 'nonexistent.h' file not found
#include <nonexistent.h>
^
1 error generated.
Clang, or at least the version that Apple ships with Xcode, does not support OpenMP. Consult the MATLAB documentation of the mex command on how to select a different compiler. Basically, you have to execute:
mex -setup
If MATLAB detects several usable compilers, it should present you with the ability to pick one of them. Unfortunately, according to this table, MATLAB might not support GCC on OS X (at least it is not listed in the table).
Related
I'm trying to build a project with OpenMp on Mojave using cmake - following this method. I've tried all of the solutions presented in similar posts, but with no success. I am aware example is for High Sierra, so I might be presuming too much in following it.
My cmakelists.txt:
cmake_minimum_required(VERSION 3.9)
include_directories(${ProjectName_SOURCE_DIR}/src)
link_directories(${ProjectName_BINARY_DIR}/src)
set(CMAKE_CXX_STANDARD 14)
set (lib_SOURCES
../src/example.h
../src/example.cpp
external.cpp)
add_library(foo MODULE ${lib_SOURCES})
find_package(OpenMP REQUIRED)
target_link_libraries(foo PRIVATE OpenMP::OpenMP_CXX)
CMake error returned is:
Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)
As per this suggestion, if I add ctdegroot's fix right above the find_package line, this seems to 'help', in the sense that the cmake then reload returns:
Cannot get compiler information:
Compiler exited with error code 1: /Library/Developer/CommandLineTools/usr/bin/c++ -xc++ -Dfoo_EXPORTS -I/Users/MyUser/Documents/SomeDirectory/Project/src -I/usr/local/include -g -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -fPIC -fopenmp=libomp -Wno-unused-command-line-argument -std=gnu++14 -fpch-preprocess -v -dD -E
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
clang: error: unsupported argument 'libomp' to option 'fopenmp='
A build in this case simply returns:
clang: error: unsupported argument 'libomp' to option 'fopenmp='
I intellectually understand that the OSX clang does not properly support OpenMP, but I'm unsure how to resolve the problem. Thanks in advance.
I am trying to compile QtWebApp with Qt5.5.1 onto the latest RPI4-Raspbian Buster and I am encountering inexplicable GLIBCXX unresolved symbols
What Works : QtWebApp cross compiled from windows to armhf using qt5.5.1 binaries natively compiled on Raspbian Buster works fine with the following components
Toolchain : raspberry-gcc8.3.0.exe installed on Windows 10.
Qt Binary Libs : Native compiled on RPI4 Raspbian Buster OS and
copied over to Windows 10.
Command line :
c:/SysGCC/raspberry/bin/arm-linux-gnueabihf-g++.exe -std=c++11 -fPIC -I.
{ALL QT INCLUDE DIRS}
-IC:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/opt/vc/include
-g -rdynamic -funwind-tables -Woverflow
{ALL QTWEB SOURCE FILES}
-LC:/SysGCC/pi4/pi4qt551/lib
-lQt5Core -lQt5Gui -lQt5Widgets
-lQt5Multimedia -lQt5MultimediaWidgets
-lQt5Network -lm -lpthread -o qtweb
This produces an arm executable that worksfine on RPI-4.
What fails
When compiling natively (which is what I want as the development env) on RPI4 the compilation strangely fails with the following error :
/usr/bin/ld: /tmp/ccnnsRCD.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev##GLIBCXX_3.4.21'
What I have tried (didnt work)
1) Following suggestions from Converting std::__cxx11::string to std::string and passing -D_GLIBCXX_USE_CXX11_ABI=0 it fails with the following error :
/usr/bin/ld: /tmp/ccZfI5co.o: undefined reference to symbol '_ZNSaIcED1Ev##GLIBCXX_3.4'
where those symbol demangles to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() and std::allocator<char>::~allocator() respectively.
2) I also ran all the combinations WITH/WITHOUT -std=c++11 and D_GLIBCXX_USE_CXX11_ABI=0 and these are the errors
WITH -std=c++11, WITHOUT -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/ccnnsRCD.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev##GLIBCXX_3.4.21'
WITH -std=c++11, WITH -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/ccZfI5co.o: undefined reference to symbol '_ZNSaIcED1Ev##GLIBCXX_3.4'
WITHOUT -std=c++11, WITH -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/cctFncwz.o: undefined reference to symbol '_ZNSaIcED1Ev##GLIBCXX_3.4'
WITHOUT -std=c++11, WITHOUT -D_GLIBCXX_USE_CXX11_ABI=0
/usr/bin/ld: /tmp/cchkJYdO.o: undefined reference to symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev##GLIBCXX_3.4.21'
3) I also copied the sysroot from the raspberry-gcc8.3.0.exe install on Win10 over to RPi-4 and passed that to gcc as its --sysroot location - which also fails with the ~basic_string() unresolver error. (I dont know how to verify if the --sysroot had any effect though I checked that gcc -v output doesnt have --with_libs in it as suggested in a GCC ignores --sysroot post)
INFO: The command line is exactly the same on the RPI4-Buster other than using gcc and not passing -IC:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/opt/vc/include
Question :
How is it that (assuming no glaring compile option mismatch ;) cross compiling with a gcc 8.3 toolchain from windows to arm-linux works but the same code base when compiled natively on raspbian buster with gcc 8.3 fails with what looks like GLIBCXX version mismatch in the Raspbian Buster OS binaries ?
I am stuck on this for 2 days now. Please suggest any other steps I can try here.
Are you executing the compiler as gcc instead of g++? That would cause this problem. Invoke g++.
Otherwise, Try adding -lstdc++ to your link flags.
Explanation:
The symbols are, obviously, from the C++ standard library. Under some circumstances - at the very least, when you invoke GCC using the gcc binary rather than g++ - GCC compiles C++ code, but doesn't automatically link against the GNU C++ standard library. If for some reason this isn't resolved by invoking g++, you could try adding the -lstdc++ flag, which means "link against the library libstdc++.so or libstdc++.a which you should find in the library search path".
I want to compile the following project that's hosted on GitHub. I'm on MacOs High Sierra 10.13.5.
When I run make on the solver directory, it gives the following error after running gcc with the -static option:
g++ -o dapcstp src/bbnode.o src/bbtree.o src/bounds.o src/cputime.o
src/heur.o src/inst.o src/main.o src/options.o src/prep.o
src/procstatus.o src/sol.o src/stats.o src/timer.o src/util.o -static -
lboost_timer -lboost_system -lboost_chrono -lboost_program_options -
lboost_filesystem
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [dapcstp] Error 1
In the answer to ld: library not found for -lcrt0.o on OSX 10.6 with gcc/clang -static flag it says the following:
This option will not work on Mac OS X unless all libraries (including libgcc.a) have also been compiled with -static. Since neither a static version of libSystem.dylib nor crt0.o are provided, this option is not useful to most people.
Is there a way I could circumvent this limitation and compile the project correctly on Mac ?
Looking at the project, the -static option is superfluous and counterproductive (even on system where static linking is supported). You can just remove it.
I have a Fortran 90 program which uses lapack subroutines, and is successfully running on my Ubuntu system. Now I want to run it on Mac (OS X Version 10.11.4). I am using gfortran compiler as a part of gcc, installed from homebrew repositories, and lapack library, installed in /usr/local/lib/.
When I try to compile my code, I get the following error:
gfortran my_prog.f90 -L/usr/local/lib/ -llapack
Undefined symbols for architecture x86_64:
"_daxpy_", referenced from:
_zggbal_ in liblapack.a(zggbal.o)
...
"_ztrmv_", referenced from:
_zlarft_ in liblapack.a(zlarft.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
After some google search I understood that the problem is because the linking. When I compile it like this, everything works well:
gfortran my_prog.f90 -llapack
Also when llapack from framework accelerate is used, the compiler doesn't complain.
gfortran my_prog.f90 -framework accelerate
The libraries are of x86-64 architecture:
lipo -info *.a
input file libfftw3.a is not a fat file
input file liblapack.a is not a fat file
Non-fat file: libfftw3.a is architecture: x86_64
Non-fat file: liblapack.a is architecture: x86_64
LAPACK is not the only one which gives me an error, later the same problem appears with FFTW3. Could you please give me a hint to the solution to this problem?
FFTW is not part of the accelerate framework. If you want to use it, you need to add -lfftw3 to the compile options as well.
If the libraries are not in the default LIBRARY_PATH, you might need to specify -L/path/to/fftw/libs as well. The same holds for the include path if you are using its modules -I/path/to/fftw/includes.
Note that the vDSP part of the library also provides FFT implementations. You might not need FFTW at all.
I struggle with Caffe compilation. Unfortunately I failed to compile it.
Steps I followed:
git clone https://github.com/BVLC/caffe.git
cd caffe
mkdir build
cd build
cmake ..
make all
Running make all fails with the following error message:
[ 2%] Building NVCC (Device) object src/caffe/CMakeFiles/cuda_compile.dir/util/cuda_compile_generated_im2col.cu.o
In file included from /usr/include/cuda_runtime.h:59:0,
from <command-line>:0:
/usr/include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.9 and up are not supported!
#error -- unsupported GNU version! gcc 4.9 and up are not supported!
^
CMake Error at cuda_compile_generated_im2col.cu.o.cmake:207 (message):
Error generating /mydir/caffe/build/src/caffe/CMakeFiles/cuda_compile.dir/util/./cuda_compile_generated_im2col.cu.o
Software version:
OS: Debian.
gcc version: 5.3.1.
nvcc version: 6.5.12.
cat /proc/driver/nvidia/version result:
NVRM version: NVIDIA UNIX x86_64 Kernel Module 352.63 Sat Nov 7 21:25:42 PST 2015
GCC version: gcc version 4.8.5 (Debian 4.8.5-3)
Attempts to solve the problem
1st try
Simple solutions are often best ones, so (as suggested here) I tried to comment out macro checking gcc version from /usr/include/host_config.h (line 82). Unfortunately it doesn't work and compilation fails badly:
1 catastrophic error detected in the compilation of "/tmp/tmpxft_000069c2_00000000-4_im2col.cpp4.ii".
2nd try
I tried to run:
cmake -D CMAKE_CXX_COMPILER=g++-4.8 ..
make
but it fails with exactly the same error message (even though g++-4.8 should be accepted).
3rd try
I've found similar problem (though not related to Caffe) and I tried to solve it as suggested in the accepted answer.
What I did:
I've ran grep -iR "find_package(CUDA" caffe command and found Cuda.cmake file which has find_package(CUDA 5.5 QUIET) in line 225.
I added set(CUDA_HOST_COMPILER /usr/bin/gcc-4.8) to Cuda.cmake, line before line: find_package(CUDA 5.5 QUIET).
I removed everything from build directory and ran cmake and make again - with and without -D CMAKE_CXX_COMPILER=g++-4.8.
Unfortunately result is exactly the same. Caffe probably overwrites it somehow - I didn't figure it out how.
make VERBOSE=1 2>&1 | grep -i compiler-bindir returns nothing.
What's interesting, make VERBOSE=1 prints command that fails, which is:
/usr/bin/nvcc -M -D__CUDACC__ /mydir/caffe/src/caffe/util/im2col.cu -o /mydir/caffe/build/src/caffe/CMakeFiles/cuda_compile.dir/util/cuda_compile_generated_im2col.cu.o.NVCC-depend -ccbin /usr/bin/cc -m64 -DUSE_LMDB -DUSE_LEVELDB -DUSE_OPENCV -DWITH_PYTHON_LAYER -DGTEST_USE_OWN_TR1_TUPLE -Xcompiler ,\"-fPIC\",\"-Wall\",\"-Wno-sign-compare\",\"-Wno-uninitialized\",\"-O3\",\"-DNDEBUG\" -gencode arch=compute_20,code=sm_21 -Xcudafe --diag_suppress=cc_clobber_ignored -Xcudafe --diag_suppress=integer_sign_change -Xcudafe --diag_suppress=useless_using_declaration -Xcudafe --diag_suppress=set_but_not_used -Xcompiler -fPIC -DNVCC -I/usr/include -I/mydir/caffe/src -I/usr/include -I/mydir/caffe/build/include -I/usr/include/hdf5/serial -I/usr/include/opencv -I/usr/include/atlas -I/usr/include/python2.7 -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/mydir/caffe/include -I/mydir/caffe/build
when I add --compiler-bindir /usr/bin/gcc-4.8 flag manually, it prints error:
nvcc fatal : redefinition of argument 'compiler-bindir'
which may be related to this bug report.
Edit: I didn't notice that --compiler-bindir and -ccbin are the same options, and the latter is already set in above command that failed. When I changed -ccbin /usr/bin/cc to -ccbin /usr/bin/gcc-4.8 in above command that failed, it completes successfully. Now I need to find option in Caffe's CMake file that overwrite -ccbin in all subsequent Caffe's CMakes. Looking at cmake/Cuda.cmake:252:list(APPEND CUDA_NVCC_FLAGS ${NVCC_FLAGS_EXTRA} seems to be good way to go.
How can I successfully complete my compilation? Any help is appreciated.
Related SO questions:
host_config.h:unsupported GNU version! gcc versions later than 4.9 are not supported.
CUDA 6.5 complains about not supporting gcc 4.9 - what to do?.
cmake -D CUDA_NVCC_FLAGS="-ccbin gcc-4.8" .. && make causes successful compilation.
Now another problem showed up: linking Google's libgflags or libprotobuf fails probably due to fact that it was compiled with newer gcc version but it's not related to asked question.
My machine runs Ubuntu 15.10, and my default compiler version is gcc 5.2.1 .
Commenting out the #error directive in line 115 of file
/usr/local/cuda-7.5/include/host_config.h
(or whatever the path on your system is) did the trick for me. Caffe compiled fine, all tests ran smoothly.
On the other hand, if one chooses to ignore this and proceed to compile part of the project with one compiler version, part of the project with another (for me it was gcc-4.8 and gcc-5.2.1), linking problems will arise. The linking problems of protobuf and libgflags another answer mentions are not unrelated to this.