I’m trying to install PyTorch on ARMv7(32-bit) architecture but PyTorch doesn’t have official ARMv7 builds so i tried this unofficial build.
It installed successfully but when I import torch I get the following error
>>import torch
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.7/site-packages/torch/__init__.py", line 81, in <module>
from torch._C import *
ImportError: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.28' not found (required by /usr/local/lib/python3.7/site-packages/torch/lib/libtorch_python.so)
I tried the following
sudo apt-get update
sudo apt-get install libc6
but it seams like that i have the newest version of libc6
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6 is already the newest version (2.23-0ubuntu11).
The following packages were automatically installed and are no longer required:
busybox-initramfs cpio initramfs-tools initramfs-tools-bin initramfs-tools-core klibc-utils libdbusmenu-gtk4 libklibc
libllvm3.8 libmircommon5 linux-base
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 10 not upgraded.
Here is my GLIBCXX and GLIBC versions that i have:
strings /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | grep GLIBC
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBC_2.4
GLIBC_2.6
GLIBC_2.18
GLIBC_2.16
GLIBC_2.17
Ldd version:
ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu11) 2.23
Copyright (C) 2016 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.
Written by Roland McGrath and Ulrich Drepper.
My OS:
cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.6 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
So is it possible to install GLIBC_2.28 on my machine?
5
Answers
It is possible, but the chances of you making a mistake and rendering your system un-bootable are quite high. It is also very likely that doing so will break something else on your system (this is the reason distributions do not usually update the version of GLIBC from the one they originally shipped with).
A much better solution is to built PyTorch targeting your system (i.e. using your “normal” toolchain).
P.S. GLIBCXX has nothing to do with your problem, and just adds noise to your question.
WAIT
It was fairly easy for me to fix it.
I have installed wrong version of the websocat on my machine.
So from here https://github.com/vi/websocat/releases
I installed https://github.com/vi/websocat/releases/download/v1.8.0/websocat_1.8.0_newer_i386.deb
which caused above issues
and then i installed the another debian
https://github.com/vi/websocat/releases/download/v1.8.0/websocat_1.8.0_older_i386.deb
That solve it.
So choose the correct version and have fun.
Happy debugging 🙂
I saw the same problem trying to run Node.js 18 on Ubuntu 18 LTS. I read a lot about the nasty risks of trying to upgrade GLIBC, so in the end I opted for the safe (albeit overkill) option of upgrading to Ubuntu 20 LTS. Problem solved.
for anyone in AWS using serverless framework
I have the issue with python Eve (flask, bcrypt) (python 3.8)
add this packages with versions to requirements.txt
cryptography==3.4.8
bcrypt==3.2.2
For me, the problem was as follows:
~
in docker is mapped to~
on host).~/venv
(in both host and docker).This happened because when installing libraries, some code gets compiled on the specific architecture/os, which was different in the docker.
The solution I used was to remove the venv, and install everything from within the docker. [This required to allow the docker access to the web and to internal company servers]
On why to do it like this in the first place – in another episode.