Import Pytorch failed!

The message is below:

[martin@A08-R32-I196-2-FZ1RLP2 anaconda3]$ ipython
Python 3.6.5 |Anaconda, Inc.| (default, Apr 29 2018, 16:14:56)
Type 'copyright', 'credits' or 'license' for more information
IPython 6.4.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import torch
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-eb42ca6e4af3> in <module>()
----> 1 import torch

~/anaconda3/lib/python3.6/site-packages/torch/__init__.py in <module>()
     78     pass
     79
---> 80 from torch._C import *
     81
     82 __all__ += [name for name in dir(_C)

ImportError: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /home/martin/anaconda3/lib/python3.6/site-packages/torch/lib/libcaffe2.so)

In [2]:

I just installed Pytorch using the command:
conda install pytorch torchvision -c pytorch

What’s the right way to fix? My OS is CentOS 7

You could try to update libgcc using conda:

conda update libgcc

@ptrblck Looks like there is a further issue:

[martin@A08-R32-I196-2-FZ1RLP2 anaconda3]$ conda update libgcc

PackageNotInstalledError: Package is not installed in prefix.
  prefix: /home/martin/anaconda3
  package name: libgcc

You should use this command in your terminal.
If you are using Windows, there should be an Anaconda prompt/terminal.

I pasted the wrong message. Sorry about that.

OK, I see.
I’m not sure, if it helps you and you might want to create another conda environment first, but you could try to copy the requested lib into your conda lib folder:

cp /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /home/martin/anaconda3/lib/

My CentOS 7 doesn’t have /usr/lib/x86_64-linux-gnu/ directory:

[martin@A08-R32-I196-2-FZ1RLP2 anaconda3]$ ls /usr/lib/
binfmt.d/ dkms/ games/ java-1.5.0/ java-ext/ jvm-private/ libGL.so.1 modules-load.d/ sse2/ tuned/
cpp dracut/ gcc/ java-1.6.0/ jvm/ kbd/ locale/ polkit-1/ sysctl.d/ udev/
crda/ firewalld/ grub/ java-1.7.0/ jvm-commmon/ kdump/ modprobe.d/ python2.7/ systemd/ yum-plugins/
debug/ firmware/ java/ java-1.8.0/ jvm-exports/ kernel/ modules/ rpm/ tmpfiles.d/

But this command find it:

find/ -name libstdc++.so.6

/home/martin/anaconda3/pkgs/libstdcxx-ng-7.2.0-hdf63c60_3/lib/libstdc++.so.6
/home/martin/anaconda3/lib/libstdc++.so.6
/home/martin/anaconda3/x86_64-conda_cos6-linux-gnu/sysroot/lib/libstdc++.so.6
[martin@A08-R32-I196-2-FZ1RLP2 anaconda3]$ ls /usr/lib/
binfmt.d/       dkms/           games/          java-1.5.0/     java-ext/       jvm-private/    libGL.so.1      modules-load.d/ sse2/           tuned/
cpp             dracut/         gcc/            java-1.6.0/     jvm/            kbd/            locale/         polkit-1/       sysctl.d/       udev/
crda/           firewalld/      grub/           java-1.7.0/     jvm-commmon/    kdump/          modprobe.d/     python2.7/      systemd/        yum-plugins/
debug/          firmware/       java/           java-1.8.0/     jvm-exports/    kernel/         modules/        rpm/            tmpfiles.d/

It doesn’t have the directory.

But this command find it:

find/ -name libstdc++.so.6

/home/martin/anaconda3/pkgs/libstdcxx-ng-7.2.0-hdf63c60_3/lib/libstdc++.so.6
/home/martin/anaconda3/lib/libstdc++.so.6
/home/martin/anaconda3/x86_64-conda_cos6-linux-gnu/sysroot/lib/libstdc++.so.6

Any further comments? Thanks.

Sorry for bringing this topic to live again. I have a CentOS 7 system where the default libstdc++.so.6 is NOT providing the CXXABI_1.3.8. This I found out by executing ‘strings libstdc++.so.6 | grep CXXABI’ at the prompt. However, I do have a conda environment, which is activated, that wants to access the CXXABI_1.3.8 and points to /usr/lib64/libstdc++.so.6 instead of its own /opt/anaconda3/envs/cuda10_base/lib/libstdc++.so.6 or the eqv. /opt/anaconda3/envs/cuda10_base/x86_64-conda_cos6-linux-gnu/sysroot/lib/libstdc++.so.6. These instances do indeed provide CXXABI_1.3.8 as they should.
Does this imply that links are broken in conda? Why is the conda environment not looking in the correct place? And what can I do about it without “destroying” my sym-links in the CentOS-system? Also, it could explain the above users experience also.
Kind regards, Per v R

could you fix your issue? I have exactly the same issue.

Hi @pvr and @mina:

I ended up here looking for my problem, same error message but different app.

My app gave the error with /lib64/libstdc++.so.6 which was pointing to /lib64/libstdc++.so.6.0.19

After reading other webs, I kind of figured out I had to “replace” to where my /lib64/libstdc++.so.6 was pointing out and a newer version was located in my conda environment… so:

(sudo) rm /system/path/to/lib/libstdc++.so.6
(sudo) ln -s /path/to/conda/lib/libstdc++.so.6.0.26  /system/path/to/lib/libstdc++.so.6

So I guess it’s not the best solution but as user finally get the app works.

Hope this help. :blush:

1 Like

Thanks. I figured this out myself in the end. However as you point out it is a bad solution. To make the solution a little better I did a script to switch back and forth with “ln -s” /symbolic links pointing towards the conda env when doing Pytorch and pointing towards the old lib when doing other stuff. This prevents OS “meltdown” because of deprecated functions. And as a bonus, CentOS 8 is “soon” ready!

I used the tip from Javier_Tognarelli and solved the problem.

I had the same `CXXABI_1.3.8’ not found problem when doing ‘import torch’ within python.

In my case this happened because I had the following updated lib in the path:
/my/path/miniconda3/lib/libstdc++.so.6.0.26

To solve I simply created a symbolic link pointing to the name of the older version under the same directory:

ln -s /my/path/miniconda3/lib//libstdc++.so.6.0.26 /my/path/miniconda3/lib/libstdc++.so.6

This link simply pointed the ‘new’ version as the ‘lower’ version name and solved the bug.

I hope it helps!