So I downloaded the latest Cuda (5.0.35) script to install Cuda on my desktop on which I have Debian (kernel 2.6.32).
When I ran the script though I get an error on the log which says:
The compiler used to compile the kernel (gcc-4.3) does not exactly match the current compiler (gcc-4.7)
So I looked to install gcc-4.3 from the repositories but it isn't there. Then I downloaded the gcc-4.3 package separately but when I try to install it I get many conflicting dependencies so installing it is really not an option. I installed gcc-4.4 which is in the repositories and changed the soft link for gcc to link to the gcc-4.4 version but I get the same message above
The compiler used to compile the kernel (gcc-4.3) does not exactly match the current compiler (gcc-4.4)
So the question is, is there a way that I can install the driver successfully without relying on the gcc-4.3?
I installed a 3.2 kernel which was compiled with gcc-4.6 and that worked for me. You could also compile the old kernel using gcc-4.7 although I tried it and had some errors. The problem is that Debian uses a very old kernel so it was compiled with gcc-4.3.
Related
I have a working cuda-10.0 toolkit and 470 driver. I need to use new virtual memory management features that I found in 10.2 driver. And I can't install more than 10.x because my old video card has compute capability 3.0.
So after applying new toolkit with:
sudo sh ./cuda_10.2.1_linux.run --toolkit --silent --override
it is as I think successfully installed:
But now in folder with "cuda-10.2" there is almost nothing, "bin" folder only has uninstaller and no "nvcc" and others. And newly created link links to that "nothing". How to deal with it?
I tried official docs and googling but nothing was found.
The patch updates for CUDA 10.2 do not contain complete toolkits. The idea behind a "patch" is that it contains only the files necessary to address the items that the patch is focused on.
To get a full CUDA 10.2 CUDA tookit install, you must first install using a full CUDA 10.2 toolkit installer, and a typical filename for that would be cuda_10.2.89_440.33.01_linux.run (runfile installer to match your indicated runfile installer usage). After that, if you decide you need/want the items addressed by the patch, you must also install the desired patch.
Note the statement on the download page:
These patches require the base installer to be installed first.
I was trying to run nvcc -V to check cuda version but I got the following error message.
Command 'nvcc' not found, but can be installed with:
sudo apt install nvidia-cuda-toolkit
But gpu acceleration is working fine for training models on cuda. Is there another way to find out cuda compiler tools version. I know nvidia-smi doesn't give the right version.
Is there a way to install or configure nvcc. So I don't have to install a whole new toolkit.
Most of the time, nvcc and other CUDA SDK binaries are not in the environment variable PATH. Check the installation path of CUDA; if it is installed under /usr/local/cuda, add its bin folder to the PATH variable in your ~/.bashrc:
export CUDA_HOME=/usr/local/cuda
export PATH=${CUDA_HOME}/bin:${PATH}
export LD_LIBRARY_PATH=${CUDA_HOME}/lib64:$LD_LIBRARY_PATH
You can apply the changes with source ~/.bashrc, or the next time you log in, everything is set automatically.
As #pQB and #talonmies above mentioned you only need to install the GPU drivers (Versioned 430-470 these days) to use PyTorch. If you are using your GPU display port you should be fine.
For Cuda compilation tools you need to install the whole toolkit, which includes the driver as well. If installing manually from CLI the downloaded file, CLI will give you the option to choose the components to install or skip.
Generally, it is recommended to install the compilation tools (which are system wide) and GPU drivers together because it avoids compatibility issues.
Append:
export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="/usr/local/cuda/lib64:$LD_LIBRARY_PATH"
to
~/.bashrc
Note: your path to cuda may include a version so navigate to /usr/local/ and check for cudaXX.XX and modify the command to point to that in ~/.bashrc
I'm attempting to run a neural network built using dl4j using the GPU. The code works fine when using the native platform dependency, but when I switch to using CUDA, execution fails with an exception:
Caused by: java.lang.UnsatisfiedLinkError: ...\cuda-8.0-6.0-1.3-windows-x86_64.jar\org\bytedeco\javacpp\windows-x86_64\jnicuda.dll: Can't find dependent libraries
Here is what I have in my build.gradle:
// compile group: 'org.nd4j', name: 'nd4j-native-platform', version: '0.9.1'
compile group: 'org.nd4j', name: 'nd4j-cuda-8.0-platform', version: '0.9.1'
Here are the dependencies showin in IDEA:
I was able to install the CUDA Toolkit and build the examples just fine. Running deviceQuery shows that my CUDA Driver / Runtime version is 9.1, is this a problem since the nd4j-cuda-8.0-platform references 8.0? Not sure, since the version is 0.9.1, which matches my CUDA version and there does not seem to be a 9.0 platform available.
Is there something additional that I'm missing? If so, how do I troubleshoot/resolve this?
So, it turns out there are a few issues. Firstly, deeplearning4j's current release does not support CUDA 9, which I had naively installed thinking the latest and greatest is the best. CUDA 9 is supported on the latest snapshot, which I tried out, but apparently due to some issue with Gradle and snapshots, was unable to resolve the issue.
Ultimately I uninstalled everything relating to CUDA from my PC and installed CUDA 8 from scratch, restarted the computer, and now things seem to be working.
My problem is that I cannot compile a CUDA example. I believe I've got CUDA 4.0 installed correctly ( I need the old version b/c I'm trying to run GPGPU-Sim). I downloaded an NVIDIA cuda sample, namely conjugateGradient. If I cd to it and run
make
it doesn't work:
macair93278:7_CUDALibraries r8t$ cd conjugateGradient/
macair93278:conjugateGradient r8t$ ls
Makefile main.cpp
macair93278:conjugateGradient r8t$ make
Makefile:36: findcudalib.mk: No such file or directory
make: *** No rule to make target `findcudalib.mk'. Stop.
I've changed my path so that running
nvcc -V
doesn't produce an error, but gives me the version. So I think that's right.
Thanks for any help.
-bb
findcudalib.mk is missing because the individual sample you downloaded is not designed to be a complete, standalone sample. It requires a framework of other files and probably other libraries that need to be built around it.
To fix this, download the CUDA 4.0 SDK (GPU Computing SDK) from here.
Install that package. Once you have installed it, and assuming your CUDA install is otherwise intact, you should be able to change into the toplevel directory and issue make. This will build all the samples. For convenience, you may wish to issue make -k.
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.