I am trying to compile a minimal C++ code
#include <iostream>
#include <mkl.h>
#include <omp.h>
int main(int argc, char *argv[])
{
omp_set_num_threads(4);
return 0;
}
using the MKL library (icc version 17.0.4) in a MacOSX Sierra 10.12.5, using the command
icc main.cpp -o main.o -DMKL_ILP64 -I/opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/include \
-L/opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/lib -Wl,-rpath,/opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/lib -lmkl_intel_ilp64 \
-lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl
However I receive the following error when I run the program
dyld: Library not loaded: #rpath/libiomp5.dylib
Referenced from: /Users/user/C++/MKL1/./main.o
Reason: image not found
/bin/sh: line 1: 8898 Abort trap: 6 ./main.o
make: *** [run] Error 134
How to set up properly the openmpi with the MKL library? I tried to follow the instruction in https://software.intel.com/en-us/articles/dyld-library-not-loadedlibiomp5dylib?page=1#comment-1905809
by adding
source /opt/intel/compilers_and_libraries_2017.4.181/mac/mkl/bin/mklvars.sh intel64
However I still get the same error during runtime.
I have tried a few ways to solve this issue. It literally took an entire day. But here are the results,
Project Files
I created a very simple Project with just one file, named,
test.c
1. The Easiest Solution
Fixing this can be as simple as,
icc -qopenmp -qopenmp-link=static test.c
This method just tells the compiler to link to static OpenMP run-time libraries.
Interestingly, the docs at Intel C++ Compiler Docs v.15 say that this is deprecated while Intel C++ Compiler Docs v.17 do not even mention about this argument, BUT it works. Probably they forgot to take it out.
2. Another method (which I do not recommend, nor do folks at Intel)
To compile the file you can use the normal "-qopenmp" flag
icc -qopenmp test.c
This creates the "a.out" file.
This method of fixing the error makes use of command-line utility called,
install_name_tool
Using this method we can change the path of #rpath/libiomp5.dylib
install_name_tool -change #rpath/libiomp5.dylib /opt/intel/compilers_and_libraries_2018.1.126/mac/compiler/lib/libiomp5.dylib a.out
Note: In place of compilers_and_libraries_2018.1.126 it should be your version of the compiler.
3. One of the BEST (correct) ways
You can just add
export DYLD_LIBRARY_PATH="/opt/intel/compilers_and_libraries_2018.1.126/mac/compiler/lib"
To your ~/.bash_profile
And then use the normal way of compiling,
icc -qopenmp test.c
Everything works perfectly.
Quick tip: You can use the otool command line utility to check the libraries your file links to.
otool -L a.out
I found the answer on https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/645194
Basically one has to add
-Wl,-rpath,/opt/intel/compilers_and_libraries_2017.4.181/mac/compiler/lib
during compilation. Now openmp with icc works perfectly
Related
I am currently using clang11 on ubuntu to compile any c/c++ code and it works fine but when I tried to compile any code (including any standard library) to assembly code for any specific target like x86_64 (even I have x86_64) riscv with giving a flag that --target=x86_64 or --target=riscv32 I got errors for any standard library that I included in my code. A simple example:
// ex.cpp
#include<iostream>
int main(){
int a = 5;
int b = 3;
std::cout << a - b;
}
Without giving flag for a spesific target works fine:
clang++-11 -S ex.cpp -o ex.s
With --target=riscv32 flag:
clang++-11 --target=riscv32 -S ex.cpp -o ex.s
gives this error:
ex.cpp:1:9: fatal error: 'iostream' file not found
also without standard libraries gives no error even I give a spesific target.
I am searching for a solution for days but I couldn't find any proper solution for this problem, most of them says try to include gnu libraries and subfolders like -I/usr/include/x86_64-linux-gnu/c++/ but it doesn't work for me.
Please don't say use g++ compiler, for adding an optimization I need clang.
Actually I am trying to compile my codes for riscv target, linking with g++ and running with spike (doesn't differ --target=... or -target ...):
clang++-11 -target riscv32-unknown-elf -march=rv32gc -fno-addrsig -S ex.cpp -o ex.s
~/riscv/bin/riscv32-unknown-elf-g++ ex.s -o ex
~/riscv/riscv-isa-sim/build/spike --isa=RV32GC ~/riscv/riscv-pk/build/pk ex
And it works fine without include a standard library.
Now, I want to ask that
Can I solve this problem simply?
or
Can I use clang directly from riscv bin utils like ~/riscv/bin/riscv32-unknown-elf-clang++ (I saw something like this on the net but couldn't find) adding and building a submodule to my riscv directory?
Edit: As #NateEldredge said, for x86_64 target triple should --target=x86_64-linux-gnu but for riscv as a target triple riscv32-unknown-elf I still have the same errors. Is there a proper target flag for riscv any other than --target=riscv32-unknown-elf? Maybe I am missing that point.
I solved my problem by linking compilations with riscv-gnu-toolchain built and also answered a similar question here in detailed: Using Clang to compile for RISC-V
Simply we need cross-compilation.
Further information you can also look here: https://github.com/lowRISC/riscv-llvm#how-can-i-build-upstream-llvmclang-and-use-it-to-cross-compile-for-a-riscv32-target
I'm working on a C++ application. I would like to embed SpiderMonkey in the application.
I'm working with CMake, but I couldn't get that build. So, in an attempt to reduce complications, I tried the example code on this page. This wouldn't link using cmake or gcc from the command line.
So, even simpler, just to ensure I can link properly I am trying to get the following to work.
From the command line with gcc:
g++ --std=c++11
-I/home/thetasinner/moz/js/src/build_DBG.OBJ/dist/include
-L/home/thetasinner/moz/js/src/build_DBG.OBJ/js/src -DDEBUG
-Wl,--verbose -lmozjs-54a1 -lm -lz -ldl test.cpp -o test
On the following minimal code example:
#include <iostream>
#include <stdexcept>
#include "jsapi.h"
#include "js/Initialization.h"
int main(int argc, char** args) {
if (!JS_Init()) {
throw std::runtime_error("failed to initialise.");
}
std::cout << "It's alive!\n";
JS_ShutDown();
return 0;
}
Even this doesn't link. I get the errors
/tmp/ccqjx5RY.o: In function `main':
custom.cpp:(.text+0xf2): undefined reference to `JS_ShutDown()'
/tmp/ccqjx5RY.o: In function `JS_Init()':
custom.cpp:(.text._Z7JS_Initv[_Z7JS_Initv]+0xa): undefined reference to
'JS::detail::InitWithFailureDiagnostic(bool)'
collect2: error: ld returned 1 exit status
The headers are found and the linker is finding the mozjs library
attempt to open /home/thetasinner/moz/js/src/custom_build_DBG.OBJ/js/src
/libmozjs-54a1.so succeeded
-lmozjs-54a1 (/home/thetasinner/moz/js/src/custom_build_DBG.OBJ/js/src
/libmozjs-54a1.so)
I am working on Linux (Ubuntu 16.04 and Debian 8.7 tried) because that's where the build tools are. I don't even want to touch Window's yet.
The 'js' executable built in the spidermonkey build works fine, which I assume has the lib I'm trying to link inside it. So I would have thought the lib itself is built okay.
Can anybody help me resolve these linker errors? There are lots of answers to questions about much older versions of SpiderMonkey, but there's nothing for more recent versions. I'm interested in version 45 (which I've tried with very similar errors) or the tip version 52.
I'm comfortable enough digging around in the code working out how to do what I want with it once it builds, hence the interest in the latest version which isn't properly documented, I'm just completely stumped with the building step.
I suspect it's just an ordering problem on the command line:
g++ --std=c++11
-I/home/thetasinner/moz/js/src/build_DBG.OBJ/dist/include
-L/home/thetasinner/moz/js/src/build_DBG.OBJ/js/src -DDEBUG
test.cpp -o test
-Wl,--verbose -lmozjs-54a1 -lm -lz -ldl
Compilation first, followed by linking, with libraries in order of dependency. (My first guess was you'd neglected to mention mozjs on the command line. It took a second look to see it was just in the wrong place.)
Good Day Everyone,
N.B - This problem has been solved - I have provided my own solution in the answer section however the solution provided by Jonathan is much shorter. Nevertheless, this was the following question I originally posted:
I am basically trying to compile a serial library (for UART communication) on Linux however I am not really sure how to correctly compile (I have mentioned what I have done so far below), any suggestions would be highly valuable. I am using the serialib library - which is composed of 2 main files (serialib.h and serialib.cpp) , you may directly view the source code of these files here (scroll all the way to the bottom and view the files in new tabs): http://serialib.free.fr/html/classserialib.html
I transferred these files (serialib.h and serialib.cpp) to my BeagleBone Black micro-controller which is running Debian (Wheezy) , g++/gcc (Debian 4.6.3-14) 4.6.3. I wrote my own program (uart.cpp is my file name) to access the functions provided by this library, this is what I wrote:
#include <iostream>
#include "serialib.h"
#ifdef __linux__
#define DEVICE_PORT "/dev/ttyO1"
#endif
int main()
{
serialib LS;
return 0;
}
So as you can see I am trying to access the 'seriallib' class. serialib.h, serialib.cpp and uart.cpp are all in the home directory. I also manually added the iostream library in serialib.cpp as I did not see it being declared in the original source code.
Now I am really unsure of how to compile such external libraries but so far I tried the following steps:
g++ -c -Wall -Werror -fPIC serialib.c to convert to PIC which gives the following error:
distcc[3142] (dcc_parse_hosts) Warning: /home/debian/.distcc/zeroconf/hosts contained no hosts; can't distribute work
distcc[3142] (dcc_zeroconf_add_hosts) CRITICAL! failed to parse host file.
distcc[3142] (dcc_build_somewhere) Warning: failed to distribute, running locally instead
g++ serialib.cpp -L /home/debian/serialib.h which gives the following error:
/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crt1.o: In function _start':
(.text+0x30): undefined reference tomain'
collect2: ld returned 1 exit status
distcc[3210] ERROR: compile serialib.cpp on localhost failed
As of now I am still finding out how to compile this and if I manage to work this out then I'll post my solution here too. Once again any suggestion will be highly valuable. Thank you all :) .
g++ -c -Wall -Werror -fPIC serialib.c to convert to PIC which gives the following error:
The "error" is not an error, it's a warning, telling you that your distcc setup is broken, but that it compiled locally.
That command doesn't "convert to PIC", it compiles the file serialib.c and produces a compiled object file, serialib.o
g++ serialib.cpp -L /home/debian/serialib.h
This is just nonsense. It tries to build a program from serialib.cpp and use the directory /home/debian/serialib.h (which isn't a directory!) to find libraries.
You don't need to "compile a library" you can just compile both the source files and link them together into a program. Either:
g++ -c serialib.cpp
g++ -c uart.cpp
g++ serialib.o uart.o -o uart
Or all in one command:
g++ serialib.cpp uart.cpp -o uart
You should read An Introduction to GCC to understand the commands, not just enter bogus commands without understanding them.
I have found a solution to this problem, hope this helps for all the future readers with similar problems. I have my own source code uart.cpp (Given in the question) which I want to compile, the external library is serialib that contains two main files (serialib.h and serialib.cpp), you will want to replace the following commands with respect to the files you have
Step 1: Compiling with position independent code
g++ -c -Wall -Werror -fpic serialib.cpp
Step 2: Creating a shared library
g++ -shared -o libserialib.so serialib.o , here the library is libserialib.so.
Step 3: Linking your source code with library
g++ -L /home/debian -lserialib uart.cpp -o uart
g++ -L /home/debian -Wall -o test uart.cpp -lserialib
You may save the library at a different path and you may have a different name of course. Suppose you have a library called libabc.so at the directory /home/user/myDir then the commands will be like:
g++ -L /home/user/myDir -labc your_code.cpp -o your_code
g++ -L /home/user/myDir -Wall -o test your_code.cpp -labc
test is out own program, lserialib is actually looking for libserialib.so and not serialib.o as gcc/g++ assumes all libraries start with lib and end with .so or .a and you can see the same goes for labc as it will look for libabc.so thus it is important to make sure your library name begins with lib and ends with .so or .a
Step 4: Making library available at run time
Here we provide the path where the library is actually stored, I saved it in the directory /home/debian which is why my command looks like:
export LD_LIBRARY_PATH=/home/debian:$LD_LIBRARY_PATH
if your library is saved at /path/to/file then the command will look like:
export LD_LIBRARY_PATH=/path/to/file:$LD_LIBRARY_PATH
This is to help the loader find the shared library and to view this path: echo $LD_LIBRARY_PATH and to unset this: unset LD_LIBRARY_PATH
To execute the program type either ./test or ./uart and in case of any modification to the main source code (uart.cpp in this case) , simply repeat step 3. I found the following link very useful: http://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html . Thank you to all of you who took time to read this question and especially those who gave me suggestions. If anyone has more or better solutions, feel free to post them here to assist future readers :).
I was trying an openmp code with clang compiler as specified in
http://clang-omp.github.io/
I downloaded the code via git and did make and make install. It successfully installed the clang compiler with openmp support. But when I try to compile a sample code (specified in the above link), I get the following error :
/usr/bin/ld: cannot find -liomp5
I did not specify path to include and lib as mentioned in the site, but I intend to specify them while compiling on command line with -L and -I options.
$clang -I/usr/lib/gcc/i686-linux-gnu/4.6/include -fopenmp test.c -o test
However, I could not find path for iomp5 lib and hence I got the above error. Can someone please tell me how to resolve this?
At first you need to build openmp library libiomp5. You can take the latest source code here
http://llvm.org/svn/llvm-project/openmp/trunk/
Background
Hi All,
I'm trying to use Boost::MPI, at the moment I'm just trying to run the simple first example from the tutorial. I am having trouble building/running it.
I installed boost using apt-get and installed boost_mpi & boost_serialization (1.48.0) using synaptic package manager. I installed MPICH2 using apt-get.
Even though OpenMPI was never explicitly installed it appears to be on my system, I assume this is a dependency for Boost::MPI but it appears MPICH2 and OpenMPI are treading on each other's toes.
Info
If I build using
g++ test.cpp -I/usr/include/mpich2 -L/usr/lib -lboost_mpi -lboost_serialization
then run using
mpiexec -n 2 ./a.out
It throws a bunch of errors which seem to come from OpenMPI. If I try and build by linking against the OpenMPI library using
g++ test.cpp -L/usr/lib -lboost_mpi -lboost_serialization -lmpi -I/usr/include/openmpi
I get the following errors:
/usr/bin/ld: /tmp/ccJ5ezv7.o: undefined reference to symbol 'ompi_op_set_cxx_callback'
/usr/bin/ld: note: 'ompi_op_set_cxx_callback' is defined in DSO /usr/lib/libmpi.so.0 so try adding it to the linker command line
/usr/lib/libmpi.so.0: could not read symbols: Invalid operation
If I try building using mpic++ with the following command
mpic++ test.cpp -lboost_mpi -lboost_serialization
It will not link returning a bunch of errors of the form
/usr/lib/libmpich.so: undefined reference to `MPL_trid'
so I tried linking against libmpi i.e.
mpic++ test.cpp -lboost_mpi -lboost_serialization -lmpi
This builds but on running with mpiexec yields the following errors
Fatal error in PMPI_Errhandler_set: Invalid communicator, error stack:
PMPI_Errhandler_set(118): MPI_Errhandler_set(comm=0x370500, errh=0x370be0) failed
PMPI_Errhandler_set(70).: Invalid communicator
Question
It seems to me that somehow OpenMPI and MPICH2 are getting intertwined where there really shouldn't. Does anybody know how I can build against only OpenMPI or MPICH2 then run using the correct mpiexec?
Mixing code compiled against different MPI libraries is not supported in general. If your Boost::MPI is linked against Open MPI, then you must use Open MPI for the rest of your application.
To get the mpic++ as well as the other compiler wrappers and all the header files you should install the -dev package for Open MPI. If the library has been installed as a dependency then only the run-time part will be there.