I met this error when compiling a modified caffe version.
OpenCV static library was compiled with CUDA 7.5 support. Please, use the same version or rebuild OpenCV with CUDA 8.0
I have some old code may not compatible with CUDA8.0, so I want to change my cuda version for this error.
I modified my ~/.bash_profile like this
# export PYTHONPATH=$PYTHONPATH:/usr/local/cuda-8.0/lib64/
# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda-8.0/lib64
export PYTHONPATH=$PYTHONPATH:/usr/local/cuda-7.5/targets/x86_64-linux/lib/
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda-7.5/targets/x86_64-linux/lib/
But it did't work. Still the same error. What should I do? Thanks.
Change your CUDA soft link to point on your desired CUDA version. For example:
ll /usr/local/cuda
lrwxrwxrwx 1 root root 19 Sep 06 2017 /usr/local/cuda -> /usr/local/cuda-8.0/
Simply relink it with
Update:
If the symlink already exists, use this other command:
[jalal#goku ~]$ ls /usr/local/cuda
lrwxrwxrwx. 1 root root 20 Sep 14 08:03 /usr/local/cuda -> /usr/local/cuda-10.2
[jalal#goku ~]$ sudo ln -sfT /usr/local/cuda/cuda-11.1/ /usr/local/cuda
[jalal#goku ~]$ ls /usr/local/cuda
lrwxrwxrwx. 1 root root 26 Sep 14 13:25 /usr/local/cuda -> /usr/local/cuda/cuda-11.1/
ln -s /usr/local/cuda-7.5 /usr/local/cuda
(With the proper installation location)
Perhaps cleaner:
sudo update-alternatives --display cuda
sudo update-alternatives --config cuda
Maybe a bit late, but I thought it might still be helpful for anyone who comes across this question. I wrote a simple bash script for switching to a different version of CUDA within the current bash session: https://github.com/phohenecker/switch-cuda
This solution explains how you can have multiple different cuda versions installed, i.e. 10.2, 11.3 and 11.6 and switch between them. It's an extension of #w.t and makes use of update-alternatives.
Afaik, after cuda 11.x the installations on Ubuntu 20.04 cuda installations will be added to the update-alternatives maintenance automatically.
Let's say you installed cuda 10.2, cuda 11.3 and cuda 11.6 (following the official nvidia installation guide: https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html). They will all reside in:
/usr/local/cuda-10.2/...
/usr/local/cuda-11.3/...
/usr/local/cuda-11.6/...
Your update-alternatives will have two entries:
$ sudo update-alternatives --query cuda
...
/usr/local/cuda-11-3 - priority 113
/usr/local/cuda-11-6 - priority 116
Solution 1: If you want to make use of the update-alternatives make sure that your cuda symbolic link points to /etc/alternatives/cuda.
# Change the symbolic link target.
$ sudo ln -sfT /etc/alternatives/cuda /usr/local/cuda
# Check the path.
$ ll /usr/local/cuda
lrwxrwrwrwx 1 root root /usr/local/cuda -> /etc/alternatives/cuda/
Now, all that is left is to make sure /etc/alternatives/cuda points to the version you want to use, e.g. 11.3.
You can make that update with:
$ sudo update-alternatives --config cuda
and follow the instructions to change the version.
Check the path:
$ ll /etc/alternatives/cuda
lrwrwrwrwx root root /etc/alternatives -> /usr/local/cuda-11.3
almost done.
And always make sure to load the correct library PATHs in your ~/.bashrc.
Solution 2:
Directly set your /usr/local/cuda symbolic link to the correct version.
$ ln -sfT /usr/local/cuda-11.3 /usr/local/cuda
Reboot your machine and double check everything is set properly:
$ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2021 NVIDIA Corporation
Built on Mon_May3 19:15:14_PDT_2021
Cuda compilation tools, release 11.3 V11.3.109
Build cuda 11.3.r11.3/compiler.29920130_0
I solved the problem finally.
Modifying ~/.bash_profile to change the path to CUDA is the correct way. But when you changed the file, you need to relaunch the bash.
Simply source ~/.bash_profile won't work. Because source will only append the content in the file to the already existed path rather than cover it.
I switched from cuda 10.2 to 11.7. export PATH=/etc/alternatives/cuda/bin:$PATH did the trick for me. I found the solution in this thread: https://stackoverflow.com/a/40599478/7924573
Related
It seems the CuDNN installer looks for the wrong version of CUDA. What am I doing wrong? The story in full:
Ubuntu 16.04
Two versions of CUDA installed, 9.0 and 9.1. /usr/lib/cuda links to the 9.1 installation, and LD_LIBRARY_PATH seems to point to that one:
$ echo $LD_LIBRARY_PATH
/usr/local/cuda/lib64:/usr/local/lib
$ ls -l /usr/local
lrwxrwxrwx 1 root root 8 jan 22 2018 cuda -> cuda-9.1
drwxr-xr-x 15 root root 4096 dec 1 2017 cuda-9.0
drwxr-xr-x 15 root root 4096 jan 22 2018 cuda-9.1
Now I did have CuDNN 7.0 installed, wanted to replace it with version 7.1. (That may have been an unwise decision, but, I already started doing it!)
Downloaded debian installers for CuDNN 7.1.3, to go with CUDA 9.1. Tried to install it thus:
$ sudo dpkg -i libcudnn7_7.1.3.16-1+cuda9.1_amd64.deb
(Reading database ... 261910 files and directories currently installed.)
Preparing to unpack libcudnn7_7.1.3.16-1+cuda9.1_amd64.deb ...
Unpacking libcudnn7 (7.1.3.16-1+cuda9.1) over (7.1.3.16-1+cuda9.1) ...
Setting up libcudnn7 (7.1.3.16-1+cuda9.1) ...
Processing triggers for libc-bin (2.26-0ubuntu2.1) ...
/sbin/ldconfig.real: /usr/local/cuda-9.0/targets/x86_64-linux/lib/libcudnn.so.7 is not a symbolic link
As you can see, the installer looks in the cuda-9.0 directory after the library files. (Why?) The file exists but it is not a symbolic link:
$ ls -l /usr/local/cuda-9.0/targets/x86_64-linux/lib/libcudnn.so
-rwxr-xr-x 1 root root 287624224 jan 16 2018 /usr/local/cuda-9.0/targets/x86_64-linux/lib/libcudnn.so
I also tried to remove libcudnn, but I did that after the first attempt of reinstalling, so removal throws the same kind of error:
$ sudo apt-get remove libcudnn7
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
cuda-9-0 cuda-command-line-tools-9-0 cuda-core-9-0 cuda-cublas-9-0
cuda-cublas-dev-9-0 cuda-cudart-9-0 cuda-cudart-dev-9-0 cuda-cufft-9-0
cuda-cufft-dev-9-0 cuda-curand-9-0 cuda-curand-dev-9-0 cuda-cusolver-9-0
cuda-cusolver-dev-9-0 cuda-cusparse-9-0 cuda-cusparse-dev-9-0
cuda-demo-suite-9-0 cuda-documentation-9-0 cuda-driver-dev-9-0
cuda-libraries-9-0 cuda-libraries-dev-9-0 cuda-license-9-0
cuda-misc-headers-9-0 cuda-npp-9-0 cuda-npp-dev-9-0 cuda-nvgraph-9-0
cuda-nvgraph-dev-9-0 cuda-nvml-dev-9-0 cuda-nvrtc-9-0 cuda-nvrtc-dev-9-0
cuda-runtime-9-0 cuda-samples-9-0 cuda-toolkit-9-0 cuda-visual-tools-9-0
libatk-wrapper-java libatk-wrapper-java-jni python-cliapp python-markdown
python-ttystatus
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
libcudnn7 libcudnn7-dev
0 upgraded, 0 newly installed, 2 to remove and 18 not upgraded.
After this operation, 680 MB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 261909 files and directories currently installed.)
Removing libcudnn7-dev (7.1.3.16-1+cuda9.1) ...
update-alternatives: removing manually selected alternative - switching libcudnn to auto mode
Removing libcudnn7 (7.1.3.16-1+cuda9.1) ...
Processing triggers for libc-bin (2.26-0ubuntu2.1) ...
/sbin/ldconfig.real: /usr/local/cuda-9.0/targets/x86_64-linux/lib/libcudnn.so.7 is not a symbolic link
So, the bigger picture: My goal is to get CuDNN 7.1 properly installed. How do I go about to achieve that goal?
I finally managed! I went in and manually removed the .so files:
$ cd /usr/local/cuda-9.0/targets/x86_64-linux/lib/
$ sudo mv libcudnn.so bak_libcudnn.so
$ sudo mv libcudnn.so.7 bak_libcudnn.so.7
$ sudo mv libcudnn.so.7.0.5 bak_libcudnn.so.7.0.5
then installing with dpkg, and reinstalling my tensorflow-gpu which confirmed that everything finally worked:
2018-11-30 09:40:39.478559: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1115] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 2123 MB memory) -> physical GPU (device: 0, name: Quadro M2000M, pci bus id: 0000:01:00.0, compute capability: 5.0)
I work on CentOS 5.5 and my computer used gcc-4.1.2 until now, and under /usr/lib/gcc/x86_64-redhat-linux/ there were 2 indexes: 4.1.1 and 4.1.2. For using some softwares I must update the gcc.
But after I installed gcc-4.7.0 from the downloaded gcc-4.7.0.tar.gz (I did not use yum because when I tried it all servers told me that I had the latest version which was certainly not true, and perhaps this was also caused by the problem I now face with), the /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ was created just like the 4.1.1 and 4.1.2 index, so under /usr/lib/gcc/x86_64-redhat-linux/ there were 3 indexes: 4.1.1, 4.1.2 and 4.7.0. And under /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ there were 6 indexes:
bin include lib lib64 libexex share
It looked like that 4.7.0 was successfully installed but when I ran
gcc --version
the result was still
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I also ran
update-alternatives --install /usr/bin/gcc gcc /usr/lib/gcc/x86_64-redhat-linux/4.7.0 40
to raise the priority of 4.7.0, and when I ran
update-alternatives --config gcc
it said
There is 1 program that provides 'gcc'.
Selection Command
-----------------------------------------------
*+ 1 /usr/lib/gcc/x86_64-redhat-linux/4.7.0
Enter to keep the current selection[+], or type selection number:
And I printed 1, all it looked like that 4.7.0 was selected as the default gcc, but when I ran gcc --version, the result was not changed! Still 4.1.2.
After that I even removed all 4.1.2 gcc and its related programs by rpm -e and deleted the index, but the result of gcc --version became
-bash: gcc: command not found.
It didn’t change when I reinstalled the 4.7.0.
After all, when I looked for the links of /usr/bin/gcc/ I found
/usr/bin/gcc -> /etc/alternatives/gcc
and link of /etc/alternatives/gcc was
/etc/alternatives/gcc -> /usr/lib/gcc/x86_64-redhat-linux/4.7.0
this should be the result of my running the update-alternatives line, so it has worked. It did make the link to 4.7.0. So why didn’t this link call 4.7.0 in the end? I can’t find out.
I even made the direct link to 4.7.0 then:
ln -s /usr/lib/gcc/x86_64-redhat-linux/4.7.0 /usr/bin/gcc
however this still didn’t work.
I am very confused with it. I will be grateful for your help. Thank you very much!
p.s. Thank Basile Starynkevitch very much for noticing me to make these explanations:
I have /usr/bin/ in my PATH, so this should be OK.
I am teached that /usr/bin/gcc/ should be linked to an executable but not index, so the link to 4.7.0 is wrong. But could anyone tell me which executable to link to, or which executable is /usr/bin/ linked to in a common computer? This may very likely lead to the solution to the problem.
I cannot run configure one more time because configure itself requires gcc but now it is not found. So I'm afraid the problem cannot be fixed by that.
Be aware of the PATH variable. You could have some $HOME/bin/ in it.
Restore your system's gcc (so undo all the mess you have done). Then run which gcc and gcc -v to understand what is it exactly.
If you compile GCC from its source code (as distributed by the FSF), choose a recent version, e.g. GCC 8 in fall 2018.
Read carefully about installing GCC. Compile it outside of its source code. Be aware of the many configure options. I suggest to consider configuring it with some --program-suffix option (such as --program-suffix=-8) and then adding symlinks (e.g. $HOME/bin/gcc -> /usr/local/bin/gcc-8) appropriately.
ln -s /usr/lib/gcc/x86_64-redhat-linux/4.7.0 /usr/bin/gcc
it is wrong. Since /usr/lib/gcc/x86_64-redhat-linux/4.7.0/ is some internal directory, and /usr/bin/gcc has to be an executable.
You probably don't need to run update-alternatives, but you do need to add (cleverly) something in a directory mentioned in your PATH
See also this answer to a similar question.
after edits in the question
You need first to clean up the mess you did under /usr/ (in particular in /usr/bin/ which you should never change without your package system). Remove all the things you added under /usr/bin/ and /usr/lib/. Then re-install forcibly and explicitly appropriate system gcc packages (using yum or some other package manager).
I have /usr/bin/ in my PATH, so this should be OK.
Probably not. My recommendation is to have $HOME/bin/ and /usr/local/bin/ early in your PATH (so before /usr/bin/; you might need to edit ~/.bashrc to change your PATH setting) and to add your new gcc, as something like gcc-8 (if you compile GCC 8 from its source code), there. If you want a system wide installation, have some /usr/local/bin/gcc-8 program. If you want a personal installation, have some $HOME/bin/gcc-8 program (both could be absolute symlinks to somewhere else).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I installed Tensorflow 1.6.0 - GPU version with anaconda in a Python 3.6.4 environment.
When I do import tensorflow as tf, I get the following error:
ImportError: libcudnn.so.7: cannot open shared object file: No such file or directory
The different versions:
cudnn : 7.1.1
cuda : 9.0.176
tensorflow : 1.6.0
Ubuntu : 16.04
I am aware of this but it did not solve my problem.
The accepted answer is wrong (installing nvidia-cuda-toolkit). By installing the toolkit you are basically installing a second CUDA on top of already installed cuda from the nvidia guide.
The problem turned out to be an issue with symbolic links. Inspiration is from this topic http://queirozf.com/entries/installing-cuda-tk-and-tensorflow-on-a-clean-ubuntu-16-04-install
but the actual resolution is different
So at one point during CuDNN installation nvidia tutorial will ask you to do this:
sudo cp cuda/include/cudnn.h /usr/local/cuda/include
sudo cp cuda/lib64/libcudnn* /usr/local/cuda/lib64
sudo chmod a+r /usr/local/cuda/include/cudnn.h /usr/local/cuda/lib64/libcudnn*
The problem with this approach is that copying files with filter libcudnn* will break the symbolic links of the copied files. Instead, I suggest runnign following command, but it will still break the links:
sudo cp --preserve=links cuda/lib64/libcudnn* /usr/local/cuda/lib64
You can verify the links by running ls -lha libcudnn* in /usr/local/cuda/lib64 folder. If you happen to not see a picture like this:
lrwxrwxrwx 1 root root 13 May 2 20:02 libcudnn.so -> libcudnn.so.7
lrwxrwxrwx 1 root root 17 May 2 20:02 libcudnn.so.7 -> libcudnn.so.7.6.5
-rwxr-xr-x 1 root root 409M May 2 20:02 libcudnn.so.7.6.5
-rw-r--r-- 1 root root 386M May 2 20:02 libcudnn_static.a
Then you just found the problem. The actual solution is involving doing the following:
sudo rm /usr/local/cuda/lib64/libcudnn.so
sudo rm /usr/local/cuda/lib64/libcudnn.so.7
cd /usr/local/cuda/lib64/
sudo ln -s libcudnn.so.7.6.5 libcudnn.so.7
sudo ln -s libcudnn.so.7 libcudnn.so
Remove the old "links" and create new ones. Verify the links again with ls -lha libcudnn*. After that run following command in verbose mode:
sudo ldconfig -v
CHECK the logs. I don't know exactly what it does, but it turned out that it is something very important. Also, if the log says that symbolic link is broken or something along these lines then the tensorflow will continue to show the error mentioned in the subject.
BONUS! make sure you have following paths appended as the last lines nano ~/.bashrc
export PATH=/usr/local/cuda/bin:/opt/nvidia/nsight-compute/2019.4.0${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
export CUDADIR=/usr/local/cuda${CUDADIR:+:${CUDADIR}}
export CUDA_HOME=/usr/local/cuda
and then run the command source ~/.bashrc
All of the above steps assume that you did NOT use the nvidia-cuda-toolkit, but instead used nvidia cuda repo.
Also when installing CUDA make sure you are not targeting the 10.2. On the momenent of writing TF supports versions up to Cuda 10.1, so following is the right way of installing the necessary version:
sudo apt-cache policy cuda
sudo apt-get install cuda=10.1.243-1
Verifications by:
nvcc --version
nvidia-smi
EDIT: I found the error that you should AVOID seeing after running the ldconfig command:
/usr/local/cuda-10.1/targets/x86_64-linux/lib:
...
libnppist.so.10 -> libnppist.so.10.2.0.243
libcuinj64.so.10.1 -> libcuinj64.so.10.1.243
> /sbin/ldconfig.real: /usr/local/cuda-10.1/targets/x86_64-linux/lib /libcudnn.so.7 is not a symbolic link
libcudnn.so.7 -> libcudnn.so.7.6.5
libnppc.so.10 -> libnppc.so.10.2.0.243
libnppicom.so.10 -> libnppicom.so.10.2.0.243
libnvgraph.so.10 -> libnvgraph.so.10.1.243
/usr/lib/x86_64-linux-gnu/libfakeroot:
...
If you see it, then something is still misconfigured.
I don't have enough reputations to comment on Alex's answer. But now on Ubuntu 20.04 the paths have been changed! Also, no need to --preserve=links now when doing cp! So I should probably post a new answer:
Install cuDNN library 7.6 for TensorFlow 2.3.1 with CUDA 10.1, in an environment created by conda create --name tfgpu10.1 python=3.8:
Go to https://developer.nvidia.com/cuDNN
Download "cuDNN Library for Linux" in "Download cuDNN v7.6.5 (November 5th, 2019), for CUDA 10.1"
Extract using tar -xvzf cudnn-10.1-linux-x64-v7.6.5.32.tgz
"Install" files:
sudo cp cuda/include/cudnn.h /usr/lib/cuda/include/
sudo cp cuda/lib64/libcudnn* /usr/lib/cuda/lib64/
Set permission:
sudo chmod a+r /usr/lib/cuda/include/cudnn.h /usr/lib/cuda/lib64/libcudnn*
Output of testing:
Python 3.8.5 (default, Sep 4 2020, 07:30:14)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow as tf
2020-12-02 03:58:41.089993: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.10.1
>>> tf.config.list_physical_devices("GPU")
2020-12-02 03:58:48.538295: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcuda.so.1
2020-12-02 03:58:48.587523: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2020-12-02 03:58:48.587838: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1716] Found device 0 with properties:
pciBusID: 0000:01:00.0 name: GeForce GTX 1650 Ti computeCapability: 7.5
coreClock: 1.485GHz coreCount: 16 deviceMemorySize: 3.82GiB deviceMemoryBandwidth: 178.84GiB/s
2020-12-02 03:58:48.587860: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudart.so.10.1
2020-12-02 03:58:48.589111: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcublas.so.10
2020-12-02 03:58:48.590284: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcufft.so.10
2020-12-02 03:58:48.590488: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcurand.so.10
2020-12-02 03:58:48.591785: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcusolver.so.10
2020-12-02 03:58:48.592520: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcusparse.so.10
2020-12-02 03:58:48.595129: I tensorflow/stream_executor/platform/default/dso_loader.cc:48] Successfully opened dynamic library libcudnn.so.7
2020-12-02 03:58:48.595213: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2020-12-02 03:58:48.595555: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:982] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2020-12-02 03:58:48.595815: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1858] Adding visible gpu devices: 0
[PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')]
I installed the nvidia-cuda-toolkit package:
$ sudo apt install nvidia-cuda-toolkit
and it worked.
I did not find the solution nor on the tensorflow website nor on the nvidia installation page. I found it by luck while looking for a way to get the cuda version with a command line: How to get the cuda version?
This didn't work for me, In my case it was because I had multiple versions of Cuda installed and that the cudnn version I had was for an older version than the one I was trying to use so I installed the cudnn for the new verision following nvidia's instructions and that did it for me.
I'm trying to install Quartus 13.0 on a docker container but I have a trouble with libpng12 lib.
builder#580847ded665:~$ ls -ld $(locate -r libpng.*\.so.*)
lrwxrwxrwx. 1 root root 18 Jan 6 2016 /lib/x86_64-linux-gnu/libpng12.so.0 -> libpng12.so.0.54.0
-rw-r--r--. 1 root root 149904 Jan 6 2016 /lib/x86_64-linux-gnu/libpng12.so.0.54.0
lrwxrwxrwx. 1 root root 35 Jan 6 2016 /usr/lib/x86_64-linux-gnu/libpng12.so.0 -> /lib/x86_64-linux-gnu/libpng12.so.0
builder#580847ded665:~$ xvfb-run -a /home/builder/altera/13.0/quartus/bin/tb2_install --enable
tb2_install: error while loading shared libraries: libpng12.so.0: cannot open shared object file: wrong ELF class: ELFCLASS64
The problem is I have a 32 bit application trying to use a 64 bit library and it is not understanding it. Could anyone please help me to figure out how to fix this issue?
Here's what you can do.
Download libpng12-0 package from
here.
Now head over to the folder where you've downloaded it and open the terminal from there. Switch to super user using:
sudo su
Install the downloaded package with the following command:
dpkg -i libpng12-0_1.2.50-1ubuntu2.14.04.3_amd64.deb; apt-get install -f
(The package name can change, make sure to change it accordingly).
If you get an error like this:
dpkg: error processing archive libpng12-0_1.2.50-1ubuntu2.14.04.3_amd64.deb (--install): trying to overwrite shared '/usr/share/doc/libpng12-0/changelog.Debian.gz'
This means that you might have an existing libpng package installed on your system which is causing a conflict.
Do this:
mv /usr/share/doc/libpng12-0 /usr/share/doc/libpng12-0.backup
This means that you are moving the conflict causing directory to another location.
Finally,
dpkg -i libpng12-0_1.2.50-1ubuntu2.14.04.3_amd64.deb; apt-get install -f
My answer is specific to Bionic beaver and *64 architecture. You can checkout the link provided above to download other architecture-specific packages.
Hope this helps!
Try installing 32-bit version of libpng. On Debian it should be something like apt-get install libpng16-16:i386. If tb2_install keeps picking 64-bit version you might need to update LD_LIBRARY_PATH to put 32-bit paths in front of 64-bit ones.
Another solution is to use 64-bit Quartus installer.
I have gcc-4.6 & gcc-4.7 both installed on my machine and I made gcc the default compiler. But still I could see 4.6 under "cat /proc/version" but I want 4.7 in place of 4.6.
cat /proc/version
Linux version 3.2.0-4-rt-686-pae (debian-kernel#lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP PREEMPT RT Debian 3.2.65-1+deb7u2
How can I change gcc version here from 4.6 to 4.7 ?
Any help would be really helpfull for me.
Many Thanks.
As the same problem is mentioned here https://askubuntu.com/questions/193539/having-2-versions-of-gcc
I suggest you to check the solution.
This is because you have both versions installed,and 4.6 being treated as the default.
The easiest way make gcc-4.7 the default gcc is to move the symlink of /usr/bin/gcc:
sudo rm /usr/bin/gcc
sudo ln -s /usr/bin/gcc-4.7 /usr/bin/gcc
Reference link here
Is there any way to use a module in 3.2 which is compiled with kernel
3.10 ?
You can try the option -f of modprobe.