libalpm.so.14 cannot be found with pacman in [testing]

[jlo62]

Affected Version

2.0.3-1

Description

paru is broken with the pacman version that is currently in testing (7.0.0.r3.g7736133-1). It bumps the libalpm lib version to 15.0.0

Output

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

[Spixmaster]

A rebuild does not work.

==> Beginne build()...
   Compiling proc-macro2 v1.0.79
   Compiling unicode-ident v1.0.12
   Compiling libc v0.2.153
   Compiling memchr v2.7.1
   Compiling cfg-if v1.0.0
   Compiling autocfg v1.1.0
   Compiling pkg-config v0.3.30
   Compiling cc v1.0.90
   Compiling once_cell v1.19.0
   Compiling ppv-lite86 v0.2.17
   Compiling siphasher v0.3.11
   Compiling pin-project-lite v0.2.13
   Compiling bitflags v2.4.2
   Compiling serde v1.0.197
   Compiling quote v1.0.35
   Compiling log v0.4.21
   Compiling futures-core v0.3.30
   Compiling syn v2.0.52
   Compiling itoa v1.0.10
   Compiling bytes v1.5.0
   Compiling slab v0.4.9
   Compiling futures-sink v0.3.30
   Compiling getrandom v0.2.12
   Compiling vcpkg v0.2.15
   Compiling phf_shared v0.10.0
   Compiling rand_core v0.6.4
   Compiling futures-channel v0.3.30
   Compiling rand_chacha v0.3.1
   Compiling futures-io v0.3.30
   Compiling pin-utils v0.1.0
   Compiling futures-task v0.3.30
   Compiling alpm-sys v3.0.0 (https://github.com/archlinux/alpm.rs?rev=306342#306342ef)
   Compiling equivalent v1.0.1
   Compiling rand v0.8.5
   Compiling hashbrown v0.14.3
   Compiling aho-corasick v1.1.2
   Compiling tracing-core v0.1.32
   Compiling signal-hook-registry v1.4.1
   Compiling num_cpus v1.16.0
   Compiling openssl-sys v0.9.101
   Compiling mio v0.8.11
   Compiling socket2 v0.5.6
   Compiling phf_generator v0.10.0
   Compiling indexmap v2.2.5
   Compiling phf_codegen v0.10.0
   Compiling smallvec v1.13.1
   Compiling tinyvec_macros v0.1.1
   Compiling foreign-types-shared v0.1.1
   Compiling syn v1.0.109
   Compiling fnv v1.0.7
   Compiling crossbeam-utils v0.8.19
   Compiling openssl v0.10.64
   Compiling adler v1.0.2
   Compiling regex-syntax v0.8.2
   Compiling miniz_oxide v0.7.2
   Compiling http v0.2.12
   Compiling foreign-types v0.3.2
   Compiling tinyvec v1.6.0
   Compiling tracing v0.1.40
   Compiling lock_api v0.4.11
   Compiling percent-encoding v2.3.1
   Compiling parking_lot_core v0.9.9
   Compiling new_debug_unreachable v1.0.4
   Compiling crc32fast v1.4.0
   Compiling httparse v1.8.0
   Compiling native-tls v0.2.11
   Compiling unicode-normalization v0.1.23
   Compiling form_urlencoded v1.2.1
   Compiling phf_shared v0.11.2
   Compiling unicode-bidi v0.3.15
   Compiling thiserror v1.0.58
   Compiling scopeguard v1.2.0
   Compiling openssl-probe v0.1.5
   Compiling try-lock v0.2.5
   Compiling want v0.3.1
   Compiling phf_generator v0.11.2
   Compiling regex-automata v0.4.6
   Compiling idna v0.5.0
   Compiling http-body v0.4.6
   Compiling string_cache_codegen v0.5.2
   Compiling encoding_rs v0.8.33
   Compiling precomputed-hash v0.1.1
   Compiling mac v0.1.1
   Compiling httpdate v1.0.3
   Compiling tower-service v0.3.2
   Compiling ryu v1.0.17
   Compiling temp-dir v0.1.12
   Compiling lazy_static v1.4.0
   Compiling serde_json v1.0.114
   Compiling gettext-sys v0.21.3
   Compiling markup5ever v0.11.0
   Compiling futf v0.1.5
   Compiling parking_lot v0.12.1
   Compiling url v2.5.0
   Compiling flate2 v1.0.28
   Compiling alpm v3.0.4 (https://github.com/archlinux/alpm.rs?rev=306342#306342ef)
   Compiling serde_derive v1.0.197
   Compiling tokio-macros v2.2.0
   Compiling futures-macro v0.3.30
   Compiling tokio v1.36.0
   Compiling openssl-macros v0.1.1
   Compiling futures-util v0.3.30
   Compiling regex v1.10.3
   Compiling thiserror-impl v1.0.58
   Compiling phf_macros v0.11.2
   Compiling phf v0.10.1
   Compiling async-trait v0.1.77
   Compiling utf-8 v0.7.6
   Compiling unicode-width v0.1.11
   Compiling either v1.10.0
   Compiling version_check v0.9.4
   Compiling rustix v0.38.31
   Compiling base64 v0.21.7
   Compiling dtoa v1.0.9
   Compiling dtoa-short v0.3.4
   Compiling rustls-pemfile v1.0.4
   Compiling ahash v0.8.11
   Compiling tendril v0.4.3
   Compiling html5ever v0.26.0
   Compiling phf v0.11.2
error: failed to run custom build command for `alpm v3.0.4 (https://github.com/archlinux/alpm.rs?rev=306342#306342ef)`

Caused by:
  process didn't exit successfully: `/home/matheus/Downloads/paru/src/paru-2.0.3/target/release/build/alpm-fe8130be9696cf00/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at /home/matheus/.local/share/cargo/git/checkouts/alpm.rs-a0070a235cf20bfa/306342e/alpm/build.rs:25:13:
  this version of alpm.rs does not support libalpm v15.0.0 only v14.x.x is supported
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

[samuelcordero]

@Spixmaster As the guy before you posted, you need to run a symlink in order to trick the rust compiler into thinking its libalpm v14 and not v15. Read the error, understand it, and read what was posted before. 😉

[ArielHorwitz]

@samuelcordero I can confirm I created the symlink and tried to rebuild and get the same error. I am assuming the symlink works for an already-built paru but not for building paru. (While trying to fix this in my case, I also tried reinstalling paru before finding this thread)

[Lunarequest]

hi, I found installing paru-git works you could try and build paru-git and then use paru-git to build stable if you need it

[C0rn3j]

Temporary workaround - create a symlink for now until there's an update.

sudo ln -s /usr/lib/libalpm.so.15.0.0 /usr/lib/libalpm.so.14

Worked for me, and I'll just remove the symlink when it's not needed anymore

Don't symlink different SO libraries for something that handles your system files, a package manager is the last thing you want to break on undefined behavior, the SO bump happened for a reason.

Build from master as mentioned if you absolutely can't wait for a release.

[Spixmaster]

@Spixmaster As the guy before you posted, you need to run a symlink in order to trick the rust compiler into thinking its libalpm v14 and not v15. Read the error, understand it, and read what was posted before. 😉

Your mentioned solution does not state whether it applies to running the executable or building.

[ndavd]

Build from master as mentioned if you absolutely can't wait for a release.

+1. Just do:

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

Once this issue is resolved you may go back and install paru the regular way.

[shurizzle]

This solution patches the executable instead of linking libs that you'll forget to delete

(which patchelf >/dev/null 2>/dev/null || sudo pacman -S --asdeps patchelf) && sudo patchelf --replace-needed libalpm.so.14 libalpm.so.15 "$(which paru)" && paru -c && yes | paru -Scc

[kescherCode]

@shurizzle your solution has the same issues as the symlink: It ends up using a library it was not explicitly linked against and that intentionally had an soname bump due to incompatibility reasons.

[shurizzle]

@shurizzle your solution has the same issues as the symlink: It ends up using a library it was not explicitly linked against and that intentionally had an soname bump due to incompatibility reasons.

In general you are totally right but it works to reinstall itself from master.

[anotherglitchinthematrix]

hi, I found installing paru-git works you could try and build paru-git and then use paru-git to build stable if you need it

Took ages to build rust :^) but a working solution for sure.

[kj-sh604]

cross-posting my comment from #1240:

I re-wrote the paru-git PKGBUILD, and I think it could be useful for some folks. Essentially, it builds the latest paru git commit into a regular paru release package instead of a paru-git package. That way, when the official paru package eventually gets updated, you'll automatically get the latest release without having to remember to remove paru-git. It's admittedly a bit of a quick janky re-write 😅 (I promise my AUR PKGBUILDs are much cleaner 😆), but I think it could be a decent temporary fix for some people.

pkgname=paru
_pkgname=paru
pkgver=2.0.3
pkgrel=1
pkgdesc='Feature packed AUR helper'
url='https://github.com/morganamilo/paru'
source=("git+https://github.com/morganamilo/paru")
backup=("etc/paru.conf")
arch=('i686' 'pentium4' 'x86_64' 'arm' 'armv7h' 'armv6h' 'aarch64')
license=('GPL-3.0-or-later')
makedepends=('cargo')
depends=('git' 'pacman' 'libalpm.so>=14')
optdepends=('bat: colored pkgbuild printing' 'devtools: build in chroot and downloading pkgbuilds')
conflicts=('paru-git')
provides=('paru')
sha256sums=(SKIP)

prepare() {
  cd "$_pkgname"
  cargo fetch --locked --target "$(rustc -vV | sed -n 's|host: ||p')"
}

build () {
  cd "$srcdir/$_pkgname"

  if pacman -T pacman-git > /dev/null; then
    _features+="git,"
  fi

  if [[ $(rustc -V) == *"nightly"* ]]; then
    _features+="backtrace,"
  fi

  if [[ $CARCH != x86_64 ]]; then
    export CARGO_PROFILE_RELEASE_LTO=off
  fi

  PARU_VERSION=$pkgver cargo build --frozen --features "${_features:-}" --release --target-dir target
  ./scripts/mkmo locale/
}

package() {
  cd "$srcdir/$_pkgname"

  install -Dm755 target/release/paru "${pkgdir}/usr/bin/paru"
  install -Dm644 paru.conf "${pkgdir}/etc/paru.conf"

  install -Dm644 man/paru.8 "$pkgdir/usr/share/man/man8/paru.8"
  install -Dm644 man/paru.conf.5 "$pkgdir/usr/share/man/man5/paru.conf.5"

  install -Dm644 completions/bash "${pkgdir}/usr/share/bash-completion/completions/paru.bash"
  install -Dm644 completions/fish "${pkgdir}/usr/share/fish/vendor_completions.d/paru.fish"
  install -Dm644 completions/zsh "${pkgdir}/usr/share/zsh/site-functions/_paru"

  install -d "$pkgdir/usr/share/"
  cp -r locale "$pkgdir/usr/share/"
}

[TheGentleChainsaw]

Here's a more "proper" version of the same idea that @kj-sh604 posited. It's essentially the original paru PKGBUILD with a commit pin, a valid checksum and a bumped version requirement for libalpm.so:

# Maintainer: Morgan <morganamilo@archlinux.org>
pkgname=paru
pkgver=2.0.3+g90656a9
pkgrel=1
pkgdesc='Feature packed AUR helper'
url='https://github.com/morganamilo/paru'
source=("$pkgname-$pkgver::git+https://github.com/Morganamilo/paru.git#commit=90656a9")
backup=("etc/paru.conf")
arch=('i686' 'pentium4' 'x86_64' 'arm' 'armv7h' 'armv6h' 'aarch64')
license=('GPL-3.0-or-later')
makedepends=('cargo')
depends=('git' 'pacman' 'libalpm.so>=15')
optdepends=('bat: colored pkgbuild printing' 'devtools: build in chroot and downloading pkgbuilds')
sha256sums=('b1385075347c3ec2c4dda8055fd74cb9106ea5e2ee92d76a56a9c7707932221f')

prepare() {
  cd "$pkgname-$pkgver"
  cargo fetch --locked --target "$(rustc -vV | sed -n 's|host: ||p')"
}

build () {
  cd "$srcdir/$pkgname-$pkgver"

  if pacman -T pacman-git > /dev/null; then
    _features+="git,"
  fi

  if [[ $CARCH != x86_64 ]]; then
    export CARGO_PROFILE_RELEASE_LTO=off
  fi

  cargo build --frozen --features "${_features:-}" --release --target-dir target
  ./scripts/mkmo locale/
}

package() {
  cd "$srcdir/$pkgname-$pkgver"

  install -Dm755 target/release/paru "${pkgdir}/usr/bin/paru"
  install -Dm644 paru.conf "${pkgdir}/etc/paru.conf"

  install -Dm644 man/paru.8 "$pkgdir/usr/share/man/man8/paru.8"
  install -Dm644 man/paru.conf.5 "$pkgdir/usr/share/man/man5/paru.conf.5"

  install -Dm644 completions/bash "${pkgdir}/usr/share/bash-completion/completions/paru.bash"
  install -Dm644 completions/fish "${pkgdir}/usr/share/fish/vendor_completions.d/paru.fish"
  install -Dm644 completions/zsh "${pkgdir}/usr/share/zsh/site-functions/_paru"

  install -d "$pkgdir/usr/share/"
  cp -r locale "$pkgdir/usr/share/"
}

[frazar]

This class of build issues has also happened in the past when pacman has bumped the version of the libalpm.so library.

To avoid this in the future, would it be possible to pin the PKGBUILD to a specific version of libalpm.so or pacman?

For example, take the PKGBUILD draft proposed by @TheGentleChainsaw (thanks!). Would the following change help ensure that no breakage occurs if (or when) libalpm.so.16 is published in the future?

-depends=('git' 'pacman' 'libalpm.so>=15')
+depends=('git' 'pacman' 'libalpm.so=15')

[TheBill2001]

@frazar I think doing that would prevent you from update pacman at all in the future.

If I'm right, paru resolves dependencies of repos packages, install them, and then does the same with AUR ones after, but separate. As in, paru does not resolve dependencies of new AUR packages at the same time as the ones from repos (? - correct me on this). So when there is an update for pacman with libalpm.so.16, paru will refuse to update because of dependency conflict. This is because, in this case, the already installed paru requires an older version of the library.

I guess it could prevent paru from becoming unusable. You could still update other packages that are not pacman.

[jm355]

A deeper change would be to update paru to notice this case, and warn the user that it's holding back the pacman update until paru is updated to handle it

[frazar]

@TheBill2001 You are right. Updates of pacman would be prevented if the libalpm.so=15 dependency is used instead of libalpm.so>=15. But I still think it's the best of the two solutions.

Consider the case where the libalpm.so library is pinned to version 15 in the PKGBUILD and an update to version 16 is released in a pacman update. The user would have to perform these steps to update both paru and pacman:

• uninstall paru
• update pacman
• install compatible paru version "manually" from PKGBUILD

However, I would argue that the same steps are anyway required in the scenario with libalpm.so>=15 dependency specified in the PKBUILD. Indeed, since the pacman update is not prevented, it results in a broken paru installation, where any invocation results in a panic:

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

And even in this case, fixing the installation requires the same steps mentioned above, with two additional disadvantages:

1. The error message (paru: error while loading shared libraries ...) shown to the user can not be controlled (e.g., to provide helpful information on the root cause and solution). Instead, with libalpm.so=15, paru is fully functional and can inform the user of the prevented update and of the manual steps required.
2. Unless a new paru release is immediately available, the paru installation will stay broken (unless extra manual steps are performed to downgrade pacman). Instead, with libalpm.so=15, paru is fully functional.

[XxTriviumxX]

is the paru dev even aware of this?

[1Naim]

is the paru dev even aware of this?

Not sure but you can check https://github.com/Morganamilo/paru/commit/90656a901479b77cb3b7a54e393dff9a0ca6a45f and https://github.com/archlinux/alpm.rs/commit/65a14f279c2be78d889cbb631a09ad82c706aeae

[Masero11]

Hello creator of paru this is probably my first coment ever here on github I just wanted to ask if you are going to eventually merge the current version of paru-git with normal paru to fix the recent problems thank you so much in advance and sorry if I said something dumb I'm a beginner in linux and this things

[Masero11]

Hello creator of paru this is probably my first coment ever here on github I just wanted to ask if you are going to eventually merge the current version of paru-git with normal paru to fix the recent problems thank you so much in advance and sorry if I said something dumb I'm a beginner in linux and this things

I forgot to add I use arch btw xd

[xlacroixx]

I forgot to add I use arch btw xd

23 dislikes and counting. That's the Linux community for ya.

Edit: 23 dislikes and counting on this! I love this community.

[Masero11]

Thanks for the explanation

El mié, 18 sept 2024, 4:32, developomp @.***> escribió:

I normally don't like it when people create noise on other people's repo while everyone else is trying to solve a problem, but the bug has been pretty much solved in this case and there's only going to be Linux drama from this point onward, so I'll take this opportunity to reiterate an important distinction inexperienced GH users always seem to forget:

"Github is not a forum".

I'm sorry for adding negativity and potentially adding fuel to the drama, but I hope this helps more people in the long run.

And for everyone else, please understand that people rarely comment with the intention to create noise and derail the conversation. Most "dumb" comments are made by regular people who just lacks the understanding of the way people collaborate on a project.

We all make mistakes and I'm pretty sure everyone has made a bug report something along the lines of "This feature doesn't work and I use Windows 10 with 16GB RAM".

The Linux community is notoriously bad at raising new members, but if we just tune things down a bit and nudge them in the right direction, I think we'll see more people making meaningful contributions.

Also, hi Brodie!

— Reply to this email directly, view it on GitHub https://github.com/Morganamilo/paru/issues/1239#issuecomment-2357371723, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP6FYVX62SG4QNJWY2XMDEDZXDQ35AVCNFSM6AAAAABOATUJR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJXGM3TCNZSGM . You are receiving this because you commented.Message ID: @.***>

[itaranto]

I forgot to add I use arch btw xd

23 dislikes and counting. That's the Linux community for ya.

It's being disliked because it's not appropriate nor relevant for a technical discussion in a GH issue.

I enjoy the joke myself, but I prefer to see those on Reddit or some other places.

[DHDcc]

I forgot to add I use arch btw xd

23 dislikes and counting. That's the Linux community for ya.

It's being disliked because it's appropriate nor relevant for a technical discussion in a GH issue.

I enjoy the joke myself, but I prefer to see those on Reddit or some other places.

agreed

[parham-dev27]

Not a fix but a temporary workaround. sudo patchelf --replace-needed libalpm.so.14 libalpm.so.15 "$(which paru)" This updates the paru executable to use the newer version of the libalpm

[furrykef]

That workaround was already mentioned above:

This solution patches the executable instead of linking libs that you'll forget to delete

(which patchelf >/dev/null 2>/dev/null || sudo pacman -S --asdeps patchelf) && sudo patchelf --replace-needed libalpm.so.14 libalpm.so.15 "$(which paru)" && paru -c && yes | paru -Scc

To which kescherCode replied:

@shurizzle your solution has the same issues as the symlink: It ends up using a library it was not explicitly linked against and that intentionally had an soname bump due to incompatibility reasons.

If you use this workaround, it will probably be fine, but it could potentially do something horrible because of an unexpected compatibility issue. The whole reason this build of paru was broken in the first place is because it might not be compatible. "It looks like it works now" is not the same thing as compatible.

[se7en-x230]

So you recommend to wait for an official fix?

[RealStickman]

So you recommend to wait for an official fix?

You could use this git version PKGBUILD, which will upgrade with the normal paru package once a new release comes out.

https://github.com/Morganamilo/paru/issues/1239#issuecomment-2351465944

[hard-tek]

Removed paru - try to reinstall it error: failed to commit transaction (conflicting files) paru-git-debug: /usr/lib/debug/usr/bin/paru.debug exists in filesystem (owned by paru-debug) Errors occurred, no packages were upgraded. ==> WARNING: Failed to install built package(s)

[Spixmaster]

The file /usr/lib/debug/usr/bin/paru.debug already exists. That is why the content of the new package cannot be copied to that destination. Do sudo pacman -Rsn paru and in case that errors still happen, delete the conflicting files manually.