Arch Linux User Repository

yay: error while loading shared libraries: libalpm.so.13: cannot open shared object file: No such file or directory

This will happen if you upgrade pacman and yay separately If you have this error you need to manually recompile yay

pacman -S --needed git base-devel
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

I cannot delete the spam comments appearing regularly in this page, which has also led me to disable notifications from here. I remind that the best way to receive support or report a problem is through the Upstream URL.

@zeroconf nice going! glad you fixed it

would re-installing python-setuptools fix the issue?

When I tried it:

yay -S python-setuptools
warning: python-setuptools-1:63.4.1-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
error: could not open file /var/lib/pacman/local/python-setuptools-1:63.4.1-1/desc: No such file or directory
warning: could not fully load metadata for package python-setuptools-1:63.4.1-1
error: failed to prepare transaction (invalid or corrupted package)
 -> error installing repo packages

when tried to remove it:

yay -R python-setuptools
error: could not open file /var/lib/pacman/local/python-setuptools-1:63.4.1-1/desc: No such file or directory
warning: could not fully load metadata for package python-setuptools-1:63.4.1-1
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing python-setuptools breaks dependency 'python-setuptools' required by meson
:: removing python-setuptools breaks dependency 'python-setuptools' required by python-distro
:: removing python-setuptools breaks dependency 'python-setuptools' required by s-tui
 -> exit status 1

In another PC I installed that package separately before others and then I don't see that issue. I guess there I installed already fixed version of package as it was couple of hours later.

EDIT: might have to remove that empty database directory first, then re-install

Is it really good idea to delete anything from system? I guess, then un- or reinstallation will claim even more errors... I even don't know, where that database is and didn't even search as I figured out a simple solution as described below.

Finally I just created empty files as required during reinstallation process:

sudo touch /var/lib/pacman/local/python-setuptools-1:63.4.1-1/desc
sudo touch /var/lib/pacman/local/python-setuptools-1:63.4.1-1/files

... and then I could reinstall that python-setuptools package as already described above. I thought, that no harm can happen, when to generate couple of empty files, which can be easily deleted again if needed.

Now all files after reinstallaton are properly settled:

LANG=C.utf8 ll /var/lib/pacman/local/python-setuptools-1:63.4.1-1/
total 64
drwxr-xr-x 2 root root  4096 Oct 16 23:03 .
-rw-r--r-- 1 root root   578 Oct 16 23:03 desc
-rw-r--r-- 1 root root 32330 Oct 16 23:03 files
-rw-r--r-- 1 root root 21707 Oct 16 00:46 mtree

... and no more that error.

Thank you for responding and inspiring me to solve the issue!

@zeroconf would re-installing python-setuptools fix the issue?

EDIT: might have to remove that empty database directory first, then re-install

Any idea, why querying locally will issue such error? Hopefully can it be fixed. I understand, that file is missing but it is not in my power to fix it.

yay -Qs yay
error: could not open file /var/lib/pacman/local/python-setuptools-1:63.4.1-1/desc: No such file or directory
local/yay 11.3.0-1
    Yet another yogurt. Pacman wrapper and AUR helper written in go.

Querying remotely is fine, also software updating. Folder exists but is empty.

ls /var/lib/pacman/local/|grep python-setuptools
python-setuptools-1:63.4.1-1

ls -a /var/lib/pacman/local/python-setuptools-1:63.4.1-1
.  ..

Other subfolders at /var/lib/pacman/local/ contain desc file.

@hey951753 you can use yay like that if you want. i tend to use yay for aur packages only these days. but when i started with aur helpers years ago i used it for everything. it's a matter of what works best for your workflow

Are pacman wrappers like yay supposed to be used instead of pacman in every operation (e.g. installing packages from official repos, uninsralling packages), or just in AUR operations (installing packages from AUR)?

@saabzero, the question to you should really have been "is your system fully up to date"?

@callmejoe I have go 2:1.19-1 and gcc 12.2.0-1 installed using pacman

@saabzero do you have latest go and gcc versions installed?

to me compilation fails with:

/usr/lib/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/usr/bin/ld: /usr/lib/libc.so.6: unknown type [0x13] section `.relr.dyn'
/usr/bin/ld: skipping incompatible /usr/lib/libc.so.6 when searching for /usr/lib/libc.so.6
/usr/bin/ld: cannot find /usr/lib/libc.so.6
/usr/bin/ld: /usr/lib/libc.so.6: unknown type [0x13] section `.relr.dyn'
/usr/bin/ld: skipping incompatible /usr/lib/libc.so.6 when searching for /usr/lib/libc.so.6
/usr/bin/ld: /usr/lib/ld-linux-x86-64.so.2: unknown type [0x13] section `.relr.dyn'
/usr/bin/ld: skipping incompatible /usr/lib/ld-linux-x86-64.so.2 when searching for /usr/lib/ld-linux-x86-64.so.2
/usr/bin/ld: cannot find /usr/lib/ld-linux-x86-64.so.2
/usr/bin/ld: /usr/lib/ld-linux-x86-64.so.2: unknown type [0x13] section `.relr.dyn'
/usr/bin/ld: skipping incompatible /usr/lib/ld-linux-x86-64.so.2 when searching for /usr/lib/ld-linux-x86-64.so.2
collect2: error: ld returned 1 exit status