I am installing Open MPI v1.8.8 with CUDA v7.5 on my Linux Debian.
I have tested CUDA and it works, tested OpenMPI and it works too. But when i try to combine them into a program, i meet an error: cannot find cuda.h file . This is my scenario:
My program source code include these .h file
include "cuda.h"
include "mpi.h"
I run command:
mpicc <filePath> -o test
And error appear:cuda.h: No such file or directory
#include "cuda.h"`
omp_info give me : mca:mpi:base:param:mpi_built_with_cuda_support:value:false
I have googled , and i followed some methods i found:
./configure --with-cuda
./configure --with-cuda=/usr/local/cuda-7.5
( source link : http://mirror.its.dal.ca/openmpi/faq/?category=buildcuda)
After that, i remake all , remake install Open Mpi. I run: mpicc or mpirun, the compiler give me error : mpirun error mca: base: component find: unable to open /usr/local/lib/openmpi/mca_mpool_sm
I set up soft link : ln -s /usr/local/cuda/include /usr/include ( describe in link : Building CUDA-aware openMPI on Ubuntu 12.04 cannot find cuda.h).
But it cannot fix my issue.
Does anyone successfully install it? Please help me or share your experience.
Thanks.
I think you are confusing installation problems with incorrect compiler options. It will be necessary to explicity specify the include paths, library paths, and libraries for CUDA when compiling and linking host code with your mpi wrapped host compiler.
Something like:
mpicc -I/usr/local/cuda-7.5/include -L/usr/local/cuda-7.5/lib -o test <filePath> -lcuda
would be the normal way to build a simple MPI program which call the cuda driver APIs. You will need to add nvcc compilation for device code and host code which uses the runtime API.
The apparent lack of CUDA support in your MPI flavour is a separate question and one you should probably take up in another forum (like the user mailing list of the MPI flavour you use).
Related
while compiling I get the following warning:
/usr/bin/ld: warning: libgfortran.so.3, needed by /usr/openmpi-4.0.3rc4/lib64/libmpi_usempi.so, may conflict with libgfortran.so.5
It does create the .exe but when executing it an error occurs:
ideal.exe: error while loading shared libraries: libgfortran.so.5: cannot open shared object file: No such file or directory
I search for it to try and link it but it didn't work
whereis libgfortran.so.5
libgfortran.so: /usr/lib64/libgfortran.so.3
I don't have much knowlegde about linux or compilers and I'm working on a SUSE server without sudo permission. The gnu fortran compiler I'm using is in my home directory /home/gomezmr/gcc . Does anyone know how to solve this? Thank you.
Your OpenMPI library was compiled for a different version of GCC/gfortran than the version you are using for compiling. The MPI library must be compiled for the same compiler version that you are using for compiling.
In simple cases it may happen that it will somehow work anyway, but problems like yours can happen. When using the mpi or mpi_f08 modules, the major release version must match (e.g. both GCC9 or both GCC 11,...).
If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.
I am new to Cassandra. I installed c++ driver from Datastax. Can some one please provide me the steps like in which path I have to create the ‘.c’ file and how I can compile it. I can see some example programs in example folder. Can anyone plz tell me how to compile the example programs.
The cpp-driver uses cmake and depends on libuv. So the first steps would be to ensure you have cmake installed as well as libuv. Depending on your linux distribution it may be as simple as using package manager like apt or yum (i.e. sudo apt-get install cmake libuv-dev)
Building is just a matter of running the following steps in the cpp-driver directory:
cmake .
make
sudo make install
This will install libcassandra.so to somewhere in your lib path. You can then link by providing '-lcassandra' in your parameters to clang or gcc (i.e. clang myfile.c -o myfile -lcassandra)
There is very comprehensive documentation on building from source here.
I'm attempting to compile a relatively simple Fortran executable so that it can be passed around to other Windows users that don't have Cygwin (or something of the sort) installed, however, I'm unable to get the executable to operate as a standalone. I've tried gfortran -static file.f and gfortran -static-libgfortran file.f, however other users always encounter this error:
The program can’t start because cygwin1.dll is missing from your computer. Try reinstalling the program to fix this problem.
From what I've read online (e.g. here), the -static option should be sufficient. I have verified that running the executable from my machine (DOS prompt) does work.
I have gcc (gfortran) version 4.7.3. I should also point out this is my first attempt at compiling portable Fortran.
Update
After realizing that this isn't a gfortran-specific issue (thanks to replies here), searches led me to related posts here and here
This is partially explained in the Cygwin FAQ. The solution is to install the mingw64-i686-gcc-fortran package with its dependencies, and cross-compile your code with i686-w64-mingw32-gfortran -static.
Just package the cygwin1.dll along with your binary file (both in the same folder) then it will run just fine.
I have never done any major programing outside of VS08.
I am trying to compile a program called LAMMPS with either of the two relevant make files. One calls g++ and the other calls icc (Intel's compiler).
icc produces this error:
icc -O -DLAMMPS_GZIP -DMPICH_SKIP_MPICXX -DFFT_FFTW -M write_restart.cpp > write_restart.d
write_restart.cpp(15): catastrophic error: cannot open source file "mpi.h"
#include "mpi.h"
and g++ throws this error
g++ -g -O -DLAMMPS_GZIP -DMPICH_SKIP_MPICXX -DFFT_FFTW -M verlet.cpp > verlet.d
pointers.h:25: fatal error: mpi.h: No such file or directory
compilation terminated.
The mpi.h file is located in /usr/lib/openmpi/include
It is my understanding that I need to set that $PATH variable which reads
bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/opt/intel/bin:/usr/lib/openmpi/include:
and $LD_LIBRARY_PATH which currently reads
/usr/lib/openmpi/lib:
SO, how does one include the mpi.h file? So that either icc or g++ find it?
mpi.h is a header for MPI library. That would be included if you use mpic++ MPI compiler wrapper instead of g++ in your makefile. mpic++ will call the appropriate compiler. From what you describe you have openmpi package installed on your ubuntu machine.
For more info, you need to consult the manual, e.g.
http://lammps.sandia.gov/doc/Section_start.html#2_2 (for LAMMPS)
and perhaps you need to see openmpi manual as to how to set up additional compiler. Not sure if this can be done after openmpi itself has been built. By default I think in Ubuntu openmpi compiler wrappers would only call g++. CMIIW.
Okay, so I got it to work with g++ when setting up cc as "mpic++.mpich2" instead of "mpic++"
you can try compile using openmpi make file in /src/MAKE
make openmpi
in my case, this option was successful