Manjaro SafeAUR Updater › AUR broken after update

AUR package stopped working after a Manjaro update: “cannot open shared object file”

An AUR program that worked last week now dies with error while loading shared libraries: libfoo.so.1: cannot open shared object file: No such file or directory, or, if it is written in Python, with No module named …. The only thing that changed was a Manjaro update. This page explains why, shows how to find every affected package by hand, and how to rebuild them so they stay fixed.

Why a Manjaro update breaks AUR packages

pacman upgrades packages that come from a repository. An AUR package was built on your machine and installed with pacman -U; from then on it is a foreign package, and nothing in a repository upgrade rebuilds it. The Arch wiki is explicit that this is your job: “If packages in the official repositories are updated, you will need to rebuild any AUR packages that depend on those libraries.” Manjaro’s wiki puts it more bluntly in its AUR article: “When Manjaro is updated, AUR packages might stop working.”

Compiled programs: the old soname is gone

When a library makes an incompatible change it gets a new soname: libfoo.so.1 becomes libfoo.so.2. Arch ships only one version of each shared library, and Manjaro’s repositories follow it, so the upgrade removes libfoo.so.1. A binary built against the old library still names it in a DT_NEEDED entry of its dynamic section. The dynamic loader looks for exactly that name, does not find it, and the program fails to start with the error above.

pacman sees nothing wrong. The package is installed, its files are present, and a dependency declared as plain libfoo is still satisfied by the new version.

Why Manjaro makes the timing worse

The AUR targets current Arch. Manjaro’s Stable branch deliberately does not: packages reach it after “roughly a couple of weeks testing by the users of the Unstable/Testing repos”, in the words of Manjaro’s branch documentation. The AUR side of a library transition therefore happens on Arch’s schedule and your side happens on Manjaro’s.

That gap removes the usual safety net. If an AUR maintainer bumps pkgrel to rebuild against Arch’s new library, your AUR helper picks that up while you still have the old library and builds against the old one. When Manjaro finally ships the new library, there is no new AUR release to prompt another build. Nothing tells you. A program may fail at once, or only the next time it loads the plugin that links the missing library.

Python packages: stranded in the old site-packages

A pure-Python AUR package has no ELF file to fail. It installs into a versioned directory such as /usr/lib/python3.12/site-packages, and when Manjaro moves python to a new minor version the interpreter stops looking there. The package is still installed; it is never imported again. The symptom is ModuleNotFoundError: No module named '…' from whatever imports it, and the Arch wiki states that a package “built with previous Python version must be rebuilt against the new one in order to be properly used.”

Find the affected packages by hand

1. List the packages pacman did not install from a repository

pacman -Qm

This lists foreign packages: everything from the AUR, plus anything you installed by hand or that has since been dropped from the repositories. pacman -Qmq prints the names only, which is what the next step uses.

2. Run ldd over every file they own

for p in $(pacman -Qmq); do
  pacman -Qlq "$p" | while read -r f; do
    [ -f "$f" ] && ldd "$f" 2>/dev/null | grep -q '=> not found' && echo "$p  $f"
  done
done

pacman -Qlq lists each package’s files, [ -f ] skips the directories, and ldd prints libfoo.so.1 => not found for every DT_NEEDED entry it cannot resolve. Each line of output names a package and one of its files. Files that are not dynamic ELF objects make ldd fail, and 2>/dev/null hides that. The loop runs ldd on every file, so it is slow if you have many AUR packages.

To see which library a flagged file is missing:

ldd /path/from/the/output | grep 'not found'

Two false positives. Some prebuilt applications, often -bin packages, ship private libraries in their own directory and find them through an $ORIGIN RPATH on the main executable. Standalone ldd on one of their plugins cannot see that path and reports the sibling library as missing. If pacman -Qlq <pkg> | grep libbar.so shows the package ships that file itself, it is not a break. Separately, a component may reference an optional library that is never actually loaded.

The ldd(1) man page warns that ldd may execute the program it inspects. That is acceptable for packages you installed and already run; do not point it at files you have not.

3. Look for a previous Python’s directory

python --version
ls -d /usr/lib/python3.*

If there is a python3.X directory other than the one for your current version, ask pacman who still owns it, substituting the stale version number:

pacman -Qoq /usr/lib/python3.12

Every package listed was built for an interpreter you no longer have. After a full upgrade the repository packages have moved to the new directory, so what remains is normally AUR packages.

Or let checkrebuild do it

The Arch wiki points to the rebuild-detector package for exactly this job: its checkrebuild tool, and a pacman hook, “can help find packages needing rebuilt.”

sudo pacman -S rebuild-detector
checkrebuild

Fix: rebuild against the libraries you now run

  1. Finish the system upgrade first. A build links against whatever is installed when it runs. Rebuilding before Manjaro ships the new library rebuilds the problem. Run sudo pacman -Syu, then rebuild.
  2. Rebuild each flagged package. From a fresh clone of its AUR repository (for a split package, clone the package base): 
    git clone https://aur.archlinux.org/package_name.git
cd package_name
makepkg -si
    -s installs build dependencies from the repositories and -i installs the result. makepkg -s does not fetch AUR dependencies, so if one broken AUR package depends on another, rebuild the dependency first. In an existing clone, git pull, then git clean -dfx to remove the old build, then makepkg -si. Your AUR helper can do the same job, provided it really rebuilds rather than deciding the installed version is already current.
  3. Do not symlink the old soname. The Arch wiki is direct about this: “do not "fix" the problem simply by symlinking. Libraries receive soname bumps when they are not backwards compatible.”

Why it matters where you build

makepkg on your own system links against everything installed there, including newer libraries pulled in from a third-party repository or the AUR. That can produce a package linked to a soname Manjaro Stable does not ship, which breaks again as soon as Manjaro’s version replaces it. A clean chroot synced to your Manjaro branch links only against what that branch provides, and its build dependencies never touch your system. A chroot synced to Arch would defeat the purpose.

Manjaro’s own tool for this is chrootbuild, from the manjaro-chrootbuild package. Its default branch is unstable, and building against the wrong branch still succeeds, so always pass yours explicitly:

pacman-mirrors --get-branch
git clone https://aur.archlinux.org/package_name.git
sudo chrootbuild -p package_name -b stable

Run chrootbuild from the directory that contains the clone, and replace stable with what pacman-mirrors --get-branch printed. The package lands in PKGDEST if your makepkg.conf sets one, otherwise in the directory you started from; install it with sudo pacman -U. chrootbuild does not resolve AUR dependencies. Build those first, or chain them in one run with -n, which installs each built package into the chroot so the next can build against it: -p dep -n -p package_name.

Automating the check

Automated: aur-rebuild-check, part of manjaro-safeaur-updater, does the find step above. For every package in pacman -Qmq it runs ldd over each file the package owns, recognising ELF objects by their magic bytes rather than their names, so binaries under /opt/<app>/ are checked too. It also flags any package with files under a /usr/lib/python3.X/ that is not the installed Python’s. It drops the two false positives: a missing soname the package ships itself (resolved at runtime through an $ORIGIN RPATH), and sonames listed, space-separated, in AUR_REBUILD_IGNORE_SONAMES (libjvm.so is ignored by default). It exits 1 when something needs rebuilding, --quiet keeps it silent when nothing does, and safeup runs it after every successful upgrade.

With --fix it offers yay -S --rebuild for the flagged set, but only after aur-pin-check has passed every package in it: a rebuild fetches the current PKGBUILD, and one whose VCS source is not pinned to an immutable revision is refused rather than rebuilt. The prompt defaults to no; --noconfirm skips it and is passed on to yay.

For prevention, aurinstall builds new AUR packages in Manjaro’s chrootbuild by default, always with an explicit -b branch taken from pacman-mirrors --get-branch, and says why whenever it falls back to yay (no manjaro-chrootbuild, a dependency chain it cannot resolve, or a -bin package). None of this can fix a package that genuinely needs a newer library than your branch has; the README’s What this does not do lists the limits.

Questions

Why didn’t pacman warn me that my AUR package would break?

pacman checks the dependencies a package declares, and an AUR package often declares a plain, unversioned dependency such as libfoo, which the new version still satisfies. The broken link is the soname recorded inside the binary, and pacman does not inspect that. Rebuilding locally built packages after a library update is left to you.

Can I symlink the old .so name to the new library?

No. A library gets a new soname when it is not backwards compatible, so the program would load a library with a different ABI from the one it was built for. The Arch wiki says explicitly not to fix missing libraries by symlinking. Rebuild the package instead.

Should I rebuild before or after the Manjaro update?

After. A build links against the libraries installed when it runs, so rebuilding before Manjaro ships the new library just rebuilds against the old one. Complete sudo pacman -Syu first, then rebuild.

Does a -bin AUR package need rebuilding?

Rebuilding a -bin package repackages the same prebuilt upstream binary, so it cannot change what that binary links against. If a -bin package reports a missing library, first check whether the package ships that library itself. If it does not, you need a newer upstream release, the missing library installed, or the source-built package instead.

How do I find AUR packages built for an old Python version?

List the versioned directories with ls -d /usr/lib/python3.* and compare them with python --version. For any older directory, pacman -Qoq /usr/lib/python3.12 (with that version number) lists the packages that still own files there. Those need rebuilding against the current interpreter.

Sources