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.
Related
I'm running on a container with 768MB ram and 512 MB swap space. I can't increase either of this. cabal install criterion always gives
Failed during the building phase.
The exception was: ExitFailure (-9)
This may be due to an out-of-memory condition.
during Compiling Criterion.Types. Is there any way around this or do I have to make do without criterion?
Set RTS flags on GHC to limit its memory usage (--ghc-options="+RTS -M600M") and avoid running multiple jobs in parallel (-j1).
Answer to #DavidAzar's comment on the answer:
#Li-yaoXia's solution worked, but then I had more problems. This is all from my rough notes as I tracked my way through the problem. So there might be a more streamlined solution.
Well, actually it compiled everything, but cabal --version still says 2.4, not 3.4. Maybe it's not in the path?
Warning: could not create a symlink in /root/.cabal/bin for cabal because
the file exists there already but is not managed by cabal. You can create a symlink for
this executable manually if you wish. The executable file has been installed at /root/.cabal/bin/cabal
There appears to be a solution here: https://stackoverflow.com/a/17030330/52236
But I have to figure out how to remove the existing symlink before redoing the cabal install and doing the recompile process all over again.
There is also this solution here, which I will try first:
updating cabal-install, but version is not changed
Ran unminimize from bash, which installs all the normal stuff to ubuntu.
First, in /bin, create a folder called /cabal-old, then copy the cabal executable to the cabal-old folder. Then remove cabal from the /bin folder.
Then create a new symlink pointing to the new cabal executable:
ln -s /root/.cabal/bin/cabal cabal
This gets cabal 3.4 to show up when doing cabal --version.
Next, install git: apt-get install git
Then go to plutus-pioneer-program/code/week01/ folder and enter cabal build
This downloads a lot of stuff from git, and then fails.
Warning: Requested index-state 2021-02-24T00:00:00Z is newer than
'hackage.haskell.org'! Falling back to older state (2021-02-23T23:53:53Z).
Resolving dependencies...cabal: Could not resolve dependencies:
[__0] trying: Win32-network-0.1.0.0 (user goal)
[__1] trying: base-4.12.0.0/installed-4.12.0.0 (dependency of Win32-network)
[__2] next goal: plutus-pioneer-program-week01 (user goal)
[__2] rejecting: plutus-pioneer-program-week01-0.1.0.0
(conflict:base==4.12.0.0/installed-4.12.0.0, plutus-pioneer-program-week01 =>base^>=4.14.1.0)
[__2] fail (backjumping, conflict set: base, plutus-pioneer-program-week01)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, Win32-network,plutus-pioneer-program-week01
I got a suggestion from someone on Stackoverflow that the
Plutus-Pioneer code might need ghc 8.10, and I'm on a version of
8.6.5, so next step is to figure out how to update that.
Before getting ghc 8.10, I apparently need to have ghcup installed,
run this as non-root user?:
curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
this started the install, but failed because I don't have 'make' installed. Run this:
apt-get install make
then re-run the curl command. The curl installer output shows ghc 8.10 being installed, but after it's done, ghc --version outputs 8.6.5 still. Another symlink issue?
I found this issue in the output:
In order to run ghc and cabal, you need to adjust your PATH variable.
You may want to source '/root/.ghcup/env' in your shell
configuration to do so (e.g. ~/.bashrc).
It also might require figuring out how to specify which version of ghc to use.
I need to update the simlink in the bin folder in order to get the correct version of ghc being used, and there are the following other links to update:
lrwxrwxrwx 1 root root 9 Mar 24 2020 ghc -> ghc-8.6.5
-rwxr-xr-x 1 root root 226 Mar 24 2020 ghc-8.6.5
lrwxrwxrwx 1 root root 13 Mar 24 2020 ghc-pkg -> ghc-pkg-8.6.5
-rwxr-xr-x 1 root root 258 Mar 24 2020 ghc-pkg-8.6.5
lrwxrwxrwx 1 root root 10 Mar 24 2020 ghci -> ghci-8.6.5
-rwxr-xr-x 1 root root 55 Mar 24 2020 ghci-8.6.5
First, created a new symlink for ghcup:
ln -s /root/.ghcup/bin/ghcup ghcup
(Although I can't remember what I needed ghcup for.)
Next, update the ghc symlinks for all 3 symlinks listed above in the /bin folder:
mv -T ghc ghc-old-link
ln -s /root/.ghcup/bin/ghc ghc
This works to get the newer version of ghc showing up in the bash shell.
Now trying to build, and it downloads and starts building a lot of stuff, but now this error happens:
cabal: Failed to build cborg-0.2.4.0 (which is required by
plutus-pioneer-program-week01-0.1.0.0). The build process was killed (i.e.SIGKILL).
The typical reason for this is that there is not enough memory
available (e.g. the OS killed a process using lots of memory).
Solution for this:
Docker -> Preferences -> Resources -> increase RAM, and swap space. In my case from 2-8GB RAM, and from 1 to 2 GB swap space.
Now it builds the Plutus Pioneer code for week 1.
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 running on a container with 768MB ram and 512 MB swap space. I can't increase either of this. cabal install criterion always gives
Failed during the building phase.
The exception was: ExitFailure (-9)
This may be due to an out-of-memory condition.
during Compiling Criterion.Types. Is there any way around this or do I have to make do without criterion?
Set RTS flags on GHC to limit its memory usage (--ghc-options="+RTS -M600M") and avoid running multiple jobs in parallel (-j1).
Answer to #DavidAzar's comment on the answer:
#Li-yaoXia's solution worked, but then I had more problems. This is all from my rough notes as I tracked my way through the problem. So there might be a more streamlined solution.
Well, actually it compiled everything, but cabal --version still says 2.4, not 3.4. Maybe it's not in the path?
Warning: could not create a symlink in /root/.cabal/bin for cabal because
the file exists there already but is not managed by cabal. You can create a symlink for
this executable manually if you wish. The executable file has been installed at /root/.cabal/bin/cabal
There appears to be a solution here: https://stackoverflow.com/a/17030330/52236
But I have to figure out how to remove the existing symlink before redoing the cabal install and doing the recompile process all over again.
There is also this solution here, which I will try first:
updating cabal-install, but version is not changed
Ran unminimize from bash, which installs all the normal stuff to ubuntu.
First, in /bin, create a folder called /cabal-old, then copy the cabal executable to the cabal-old folder. Then remove cabal from the /bin folder.
Then create a new symlink pointing to the new cabal executable:
ln -s /root/.cabal/bin/cabal cabal
This gets cabal 3.4 to show up when doing cabal --version.
Next, install git: apt-get install git
Then go to plutus-pioneer-program/code/week01/ folder and enter cabal build
This downloads a lot of stuff from git, and then fails.
Warning: Requested index-state 2021-02-24T00:00:00Z is newer than
'hackage.haskell.org'! Falling back to older state (2021-02-23T23:53:53Z).
Resolving dependencies...cabal: Could not resolve dependencies:
[__0] trying: Win32-network-0.1.0.0 (user goal)
[__1] trying: base-4.12.0.0/installed-4.12.0.0 (dependency of Win32-network)
[__2] next goal: plutus-pioneer-program-week01 (user goal)
[__2] rejecting: plutus-pioneer-program-week01-0.1.0.0
(conflict:base==4.12.0.0/installed-4.12.0.0, plutus-pioneer-program-week01 =>base^>=4.14.1.0)
[__2] fail (backjumping, conflict set: base, plutus-pioneer-program-week01)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, Win32-network,plutus-pioneer-program-week01
I got a suggestion from someone on Stackoverflow that the
Plutus-Pioneer code might need ghc 8.10, and I'm on a version of
8.6.5, so next step is to figure out how to update that.
Before getting ghc 8.10, I apparently need to have ghcup installed,
run this as non-root user?:
curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
this started the install, but failed because I don't have 'make' installed. Run this:
apt-get install make
then re-run the curl command. The curl installer output shows ghc 8.10 being installed, but after it's done, ghc --version outputs 8.6.5 still. Another symlink issue?
I found this issue in the output:
In order to run ghc and cabal, you need to adjust your PATH variable.
You may want to source '/root/.ghcup/env' in your shell
configuration to do so (e.g. ~/.bashrc).
It also might require figuring out how to specify which version of ghc to use.
I need to update the simlink in the bin folder in order to get the correct version of ghc being used, and there are the following other links to update:
lrwxrwxrwx 1 root root 9 Mar 24 2020 ghc -> ghc-8.6.5
-rwxr-xr-x 1 root root 226 Mar 24 2020 ghc-8.6.5
lrwxrwxrwx 1 root root 13 Mar 24 2020 ghc-pkg -> ghc-pkg-8.6.5
-rwxr-xr-x 1 root root 258 Mar 24 2020 ghc-pkg-8.6.5
lrwxrwxrwx 1 root root 10 Mar 24 2020 ghci -> ghci-8.6.5
-rwxr-xr-x 1 root root 55 Mar 24 2020 ghci-8.6.5
First, created a new symlink for ghcup:
ln -s /root/.ghcup/bin/ghcup ghcup
(Although I can't remember what I needed ghcup for.)
Next, update the ghc symlinks for all 3 symlinks listed above in the /bin folder:
mv -T ghc ghc-old-link
ln -s /root/.ghcup/bin/ghc ghc
This works to get the newer version of ghc showing up in the bash shell.
Now trying to build, and it downloads and starts building a lot of stuff, but now this error happens:
cabal: Failed to build cborg-0.2.4.0 (which is required by
plutus-pioneer-program-week01-0.1.0.0). The build process was killed (i.e.SIGKILL).
The typical reason for this is that there is not enough memory
available (e.g. the OS killed a process using lots of memory).
Solution for this:
Docker -> Preferences -> Resources -> increase RAM, and swap space. In my case from 2-8GB RAM, and from 1 to 2 GB swap space.
Now it builds the Plutus Pioneer code for week 1.
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
My machine: Linux RHEL 5.5.56 (64-bit), Perl 5.8.8. Postgres is not on this machine. But I can ping the Postgres machine no problem. And my machine can obviously install Perl modules from CPAN on the internet.
'uname -a' returns: Linux xxx 2.6.18-371.8.1.el5PAE #1 SMP Fri Mar 28 06:00:03 EDT 2014 i686 i686 i386 GNU/Linux
Other machine has Postgres 8.4.
I'm new to installing and using any DBI module. Detailed beginner instructions are needed.
I have root access to my Linux machine.
I think yum reports that I have 'postgresql-libs.i386' installed. `yum install | grep postgres` returns: 'postgresql-libs.i386 8.1.23-10.el5_10 installed'
Is this what I need? This is on my system.
lrwxrwxrwx 1 root root 12 May 1 20:05 /usr/lib/libpq.so.4 -> libpq.so.4.1*
-rwxr-xr-x 1 root root 130K Feb 27 07:36 /usr/lib/libpq.so.4.1*
Goal: I want to grab data from a Postgres server on another machine. I already have a db username, password, IP for the db machine.
Using cpanm I installed DBI just fine, no errors. When I installed DBD::Pg I got an error. CPAN error log follows:
cpanm (App::cpanminus) 1.6941 on perl 5.008008 built for i386-linux-thread-multi
Work directory is /root/.cpanm/work/1405531191.27414
You have make /usr/bin/make
You have LWP 6.04
You have /bin/tar: tar (GNU tar) 1.15.1
You have /usr/bin/unzip
Searching DBD::Pg on cpanmetadb ...
--> Working on DBD::Pg
Fetching http://www.cpan.org/authors/id/T/TU/TURNSTEP/DBD-Pg-3.3.0.tar.gz
-> OK
Unpacking DBD-Pg-3.3.0.tar.gz
Entering DBD-Pg-3.3.0
Checking configure dependencies from META.yml
Checking if you have version 0 ... Yes (0.88)
Checking if you have DBI 1.614 ... Yes (1.631)
Configuring DBD-Pg-3.3.0
Running Makefile.PL
Path to pg_config?
No POSTGRES_HOME defined, cannot find automatically
Configuring DBD::Pg 3.3.0
-> N/A
-> FAIL Configure failed for DBD-Pg-3.3.0. See /root/.cpanm/work/1405531191.27414/build.log for details.
Is it even possible for me to get data from the Postgres db on another machine?
Does anyone have a link to instructions on how to do this? I've already been googling stuff, reading stuff on CPAN, Stackoverflow and Perlmonks with no results.
FAQ at http://dbi.tiddlyspot.com/ has no info specific to installing DBD::Pg.
If I install Postgres via yum, will the installation overwrite any files, like libraries? If so, which ones? We do have other applications we use on this machine.
If I get this working, my first step is to show just very basic info about the DBI driver. Next step would be to show a few fields from one table in a SELECT statement.
I won't be returning millions of records, but returning 100 records is certainly in the ballpark.
Thank you!
If you use the package that is already built and available for your system, then you won't have any of these problems.
$ sudo yum install perl-DBD-Pg
... Lots of output snipped ...
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
perl-DBD-Pg x86_64 1.49-4.el5_8 centos-update 115 k
Installing for dependencies:
postgresql-libs x86_64 8.1.23-6.el5_8 centos-update 197 k
Transaction Summary
================================================================================
Install 2 Package(s)
Upgrade 0 Package(s)
Total download size: 312 k
Is this ok [y/N]:
My example uses Centos 5.8.8, but it should work just the same for RHEL.
Of course you can; it's a client/server architecture, after all!
The error in your log is due to a missing libpq5.