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.
Related
I cross-compiled ARMNN for my ARM Cortex-A9 (Debian 9) device on my host system which is x86_64 (Ubuntu 18.04).
I have successfully built ARMNN and all it's dependencies without any errors, but when I try to run the sample mnist on Cortex-A9, it gives the following error:
duu#34d456-45433g:~/ML-examples/armnn-mnist$ make test
arm-linux-gnueabihf-g++ -O3 -std=c++14 -I/home/duu/armnn/armnn/include mnist_caffe.cpp -o mnist_caffe -L/home/duu/build -larmnn -larmnnCaffeParser
/home/admin/build/libarmnn.so: undefined reference to `exp2f#GLIBC_2.27'
/home/admin/build/libarmnn.so: undefined reference to `logf#GLIBC_2.27'
/home/admin/build/libarmnn.so: undefined reference to `log2f#GLIBC_2.27'
/home/admin/build/libarmnn.so: undefined reference to `powf#GLIBC_2.27'
/home/admin/build/libarmnn.so: undefined reference to `expf#GLIBC_2.27'
collect2: error: ld returned 1 exit status
Makefile:12: recipe for target 'mnist_caffe' failed
make: *** [mnist_caffe] Error 1
I figured later that the device should have the same compiler and same GLIBC package, both with same versions as the host on which the library was compiled.
I compiled ARMNN using gcc-6.4.0 and glibc-2.27 on the host and I have gcc-6.3.0 and glibc-2.24 on Cortex-A9 device.
I managed to match the GCC versions and solve the compiler error but I am not able to find matching versions of GLIBC on Ubuntu 18.04 and debian 9.
Is there any way to install a GLIBC version on either of the systems which is common for both of them?
P.S. : Any other method to solve this issue is highly appreciated.
Here is a list of the possible options I can think of right now:
run your application while having LD_LIBRARY_PATH pointing to a directory containing the arm glibc dynamic libraries(v2.27) copied from your x86_64 system - see this post.
Re-compile your application on your target system, if possible, if your target system can use NFS for example,
cross-compile a static version of your library/application, linking it using -static -static-libgcc -static-libstdc++ - see this post.
use arm-linux-musleabihf-cross or one of his friends for cross-compiling a static version of your library/application if this did not work with gcc/g++ and glibc.
run your application in a chrooted environment containing the arm dynamic libraries you linked your application with on the x86_64 system - see this post for more details,
install docker on your Cortex-A9 system, and build a minimal debian/ubuntu docker image that contain a version of debian/ubuntu using glibc 2.27, along with your library and application, and execute the application in a container.
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).
I am trying to compile Cython code with the GCC compiler (which usually works like a charm), and as recommended on the "Using Parallelism" page I add the "-fopenmp" command to my setup file. However, when compiling I get the following error:
gcc.exe: libgomp.spec: No such file or directory
My version of gcc is 4.5.2, which I believe should support OpenMP just fine. I'm working on 64-bit Windows 7.
Any help would be appreciated!
My distro (CentOS 6.3) comes with gcc 4.4.6. Since I wanted to try out the Fortran2003 features I decided to compile gcc 4.7.
I followed the steps I found online: compiled separately first gmp, mpc, mpfr, ppl and cloog and the compiled gcc.
I run the configured script as:
configure --prefix=... --with-gmp=... --with-mpfr=... --with-mpc=... --program-suffix=-4.7 --enable-cloog-backend=isl --with-ppl=... --with-cloog=... --disable-multilib
This worked all right and I was able to compile with make & make install.
Now, when trying my new compiler with a simple test program (a hello world kind of thing) I get the error:
gfortran-4.7 -o test test.F90
/home/amcastro/gcc-4.7/output/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951: error while loading shared libraries: libcloog-isl.so.1: cannot open shared object file: No such file or directory
So I decide to set LD_LIBRARY_PATH=/home/amcastro/gcc-4.7/output/lib
and then I can compile.
When running I get the error:
./test
./test: error while loading shared libraries: libquadmath.so.0: cannot open shared object file: No such file or directory
So I set LD_LIBRARY_PATH=/home/amcastro/gcc-4.7/output/lib:/home/amcastro/gcc-4.7/output/lib64
and now the program runs normally.
The question is: Why is that my distro version of gcc (4.4.6) does not need me to set LD_LIBRARY_PATH? how does the distro gcc know where to look for these dynamically liked libraries? should I somehow make them to link statically?
I read also that setting LD_LIBRARY_FLAG is not a good idea. Is there another solution?
Thank you in advance
A.
I am attempting to compile gcc 4.4.0 on opensolaris 2009.6
Currently in the box (which is a AMD 64bit machine), I have the gcc 3.4.6 installed.
I unpacked the gcc 4.4.0 tarball.
I set the following env variables:
export CXX=/usr/local/bin/g++
export CC=/usr/local/bin/gcc
Then I ran "configure && make" and this is the error message that I got:
checking for i386-pc-solaris2.11-gcc... /export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64
checking for suffix of object files... configure: error: in `/export/home/me/wd/gcc/gcc-4.4.0/i386-pc-solaris2.11/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Anyone has any suggestion as to how to work around this error message?
/Edit:
Content of the config.log is posted here: link text
Normally the GCC build is bootstrapped, i.e. first it uses the system compiler to build GCC C compiler, and then it uses the freshly built compiler to recompile GCC once again (and then even once more time again). The configure line shows that it is not the system compiler but the already-built GCC compiler which is used for configure test there.
Since it fails, the problem is that the freshly-built GCC is somehow "stillborn" here. If config.log will not help you, I'd suggest to ask at gcc-help#gcc.gnu.org.
EDIT: Ah-ha, I think it is the assembler. You are using GNU assembler, but the unsupported options look like they were meant for Sun assembler. This should be solved by adding --with-gnu-as configure option (and then possibly having to specify its path explicitly with --with-as=/usr/gnu/bin/as)
You can also take a look at Solaris-specific GCC build instructions.
There's a readily available build for gcc4, which you can try updating. Its current version is 4.3.3. To get started, install pkg-get from OpenCSW and check out the build from the subversion repository:
svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/ gcc4
cd gcc4
gmake package