When I compile .cu file with nvcc 5.0, the compiler gives me following information.
/usr/bin/ld: skipping incompatible /usr/local/cuda-5.0/lib/libcudart.so when searching for -lcudart
It seems either a warning or an error. I don't know what the matter is.
Is there anyone knowing more details about this information?
This warning often happens when trying to link a 64-bit code with a 32-bit library, see this question: Skipping Incompatible Libraries at compile.
You need to distinguish 2 library files:
$CUDA_HOME/lib/libcudart.so, the 32-bit version of the cudart library.
$CUDA_HOME/lib64/libcudart.so, the 64-bit version of the cudart library.
(in your case, $CUDA_HOME is /usr/local/cuda-5.0)
Basically, the linker finds the 32-bit library first (-L options are searched in order) and returns that warning even if it ends up finding the proper library.
You probably need to add $CUDA_HOME/lib64 to your LD_LIBRARY_PATH environment variable before $CUDA_HOME/lib so that ld can find the proper library for your 64-bit architecture before the 32-bit version.
Related
I used below command to build binary for nvidia GPU:
clang++ -fsycl -fsycl-targets=nvptx64-nvidia-cuda simple-sycl-app.cpp -o simple-sycl-app-cuda
But got below error message:
clang++: error: cannot find 'libspirv-nvptx64--nvidiacl.bc'; provide path to libspirv library via '-fsycl-libspirv-path', or pass '-fno-sycl-libspirv' to build without linking with libspirv
I searched in both intel oneAPI installation path and cuda toolkit path, but cannot find the spirv-nvptx64-nvidiacl.bc.
Anyone knows where to find libspirv-nvptx64—nvidiacl.bc?
It looks like you are trying to compile using the DPC++ compiler for Nvidia GPUs.
This option is not included in the oneAPI release installations from the Intel website. At the moment you will need to compile the DPC++ LLVM project with this enabled to be able to use the appropriate flag to target Nvidia devices.
You can follow the instructions on this page to compile the project and then it explains how to use the ptx target. In the future Codeplay, the company I work for, intends to publish release binaries that include the ptx compiler option.
Situation
I work with Ubuntu 14.04. I am building GNU Octave 4.2.1 from source with GNU 6.3.0. This version of Octave is quite new, but I see the issue arising also when trying to compile older Octave releases (down to 3.8.1).
I configure the build of Octave with
${sourcedir}/configure --prefix=/opt/octave/4.2.1 \
--with-java-homedir=/usr/lib/jvm/default-java \
--with-java-libdir=/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server
Issue
The compilation is successful but the undesired warning shows up
configure: WARNING: ARPACK library found, but does not seem to work properly; disabling eigs function
I would rather like to have the eigs() function in place.
Information
I have built ARPACK-ng myself with the same compiler. All tests in the test suite (make check) are passed. The environment variables LD_LIBRARY_PATH and PKG_CONFIG_PATH point to the ARPACK library directory as intended. The configure file of Octave recognizes that location correctly, as seen before.
Besides, I get the same message if I compile Octave in another computer where ARPACK is installed natively (libarpack2 and libarpack2-dev version 3.1.5-2). It does not change a thing if I also install the related extra libraries libarpack++2c2a and libarpack++2-dev using the package repository. So the issue appears to be independent of the origin of the ARPACK files.
The part of the configure.ac file of Octave that throws this error is
### Check for ARPACK library.
save_LIBS="$LIBS"
LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS"
OCTAVE_CHECK_LIB([arpack], ARPACK,
[ARPACK not found. The eigs function will be disabled.],
[],
[dseupd],
[Fortran 77], [don't use the ARPACK library, disable eigs function],
[warn_arpack=
OCTAVE_CHECK_LIB_ARPACK_OK(
[AC_DEFINE(HAVE_ARPACK, 1, [Define to 1 if ARPACK is available.])],
[warn_arpack="ARPACK library found, but does not seem to work properly; disabling eigs function"])])
LIBS="$save_LIBS"
The farthest I go in tracing back the issue is that the subroutine OCTAVE_CHECK_LIB_ARPACK_OK issuing the warning lives in the file ${octave_source}/m4/acinclude.m4. It is written in m4 language, which I don't know
Question
Is it possible to understand why ARPACK 'does not seem to work properly'?
Is there any workaround for this?
Is this a false alarm or a bug?
I just upgraded from CUDA 4.2 to CUDA 5.0. Not surprisingly, the library that used to be named libcudart.so.4 is now called libcudart.so.5.0. After recompiling my code with nvcc 5.0, and attempting to running the code, I got this message:
./main: error while loading shared libraries: libcudart.so.4: cannot open shared object file: No such file or directory
Yeah, you stupid system, I know there's no libcudart.so.4. That's because it's now called libcudart.so.5.0. Why is it looking for libcudart.so.4 instead of libcudart.so.5.0, and how can I fix it?
What I've tried so far:
I've checked that all my paths are in order. These environment variables are set:
export PATH=$PATH:/usr/local/cuda/bin:/usr/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib:/usr/local/cuda/lib64:/lib
#note: /usr/local/cuda is symlinked to /usr/local/cuda-5.0
I've verified that libcudart.so.5.0 can be found in one of the LD_LIBRARY_PATH directories.
I recompiled my CUDA application with the the CUDA 5.0 version of nvcc. I successfully compiled and ran my application on an other machine with CUDA 4.2, and on an other machine with CUDA 4.0.
I confirmed that nvcc is really on version 5.0:
user#host$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2012 NVIDIA Corporation
Built on Fri_Sep_21_17:28:58_PDT_2012
Cuda compilation tools, release 5.0, V0.2.122
I'd like to get this question off the unanswered list, and I don't think #Jared Hoberock will mind, so I'm going to post his comment as an answer. If there's a concern and Jared or solvingPuzzles posts an answer, I'll delete mine (assuming it's not accepted -- I can't delete an accepted answere AFAIK).
nvcc seems to be statically linking against libcudart.a version 4.
Somewhere in your lib path, it seems that nvcc is finding an old libcudart.a, which needs to be removed.
For other readers, it's probably just sufficient to find all instances of libcudart.* on the system and delete any that don't match your desired CUDA version (assuming you're not trying to run a machine with multiple CUDA versions available -- in that case, the library paths for both compiling and running have to be managed appropriately)
I run code using nvcc command and it gave correct output but when I run the same code on the nsight eclipse it gave wrong output. Any one have any idea why is this behavior.
Finally I found there is problem in one of the array allocation.While the command line doesn't make any problem the nsight does.
Nsight EE builds the projects by generating make files based on the project settings and by invoking the OS make utility to build the project. It is using nvcc compiler found in the PATH but it relies on some newer options introduced in NVCC compiler 5.0 (that is a part of the same toolkit distribution).
Please do a clean rebuild in Nsight Eclipse - it will print out the command lines used to build your application. Then you can compare that command line with the one you use outside. Possible differences are:
Nsight specifies debug flags and optimization flag when building in debug and release modes.
By default, Nsight sets the new project to build for the hardware detected on your system. NVCC default is SM 1.0.
Make sure the compiler used by Nsight and from the command line are one and the same. It is possible that you have different compilers (e.g. 4.x and 5.0) installed on your system that may generate a slightly different code.
In any case, it is likely your code has some bug that manifests itself under different compilation settings. I would recommend running CUDA memcheck on you program to ensure there is no hidden bugs.
I went forward and compiled an existing c code via llvm-gcc -emit-llvm -c to llvm bitcode. The c program consisted of four modules which I built to one big bitcode each via llvm-ld. Then I tried to merge these 4 bitcode files to one via llvm-ld GE.bc GA.bc SD.bc SH.bc -o prog which works without complaint.
Trying to execute the bitcode though it complains:
LLVM ERROR: Program used external function 'myFunction' which could not be resolved!
The thing is myFunction should be defined in SD.bc and used also in GA.bc.
But it's not to find in SD.bc - does llvm-ld skip all definitions that are not used!?
My OS is Linux and I use llvm version 2.6.
As a note llvm is on version 2.9 with 3.0 approaching. You should really upgrade.