Problems with libicuuc.so

Issues & Assistance
1

Hello there, im having a weird problem after my latest update..

Since i just now updated my garuda gnome, it has refused to open my gnome terminal, remmina and possible theres more applications..
I've had to install XTerm to check what is going on, and while trying to open gnome-terminal from XTerm, I'm getting the error

gnome-terminal: error while loading shared libraries: libicuuc.so.71: cannot open shared object file: No such file or directory.

I've tried to refresh mirrors, and run sudo pacman -Syyu, no luck.
I've checked the /etc/locale.gen to make sure theres nothing there, as I've seen that problem before. Nothing...

What to do here..

2

Have you rebooted?

3

I always reboot after a larger update, especially if it contains kernel updates.

4

What does pacman -Qo gnome-terminal show?

5

Shows:
/usr/bin/gnome-terminal is owned by gnome-terminal-fedora 3.45.90-1

I've tried to run
pacman -Qi gnome-terminal icu lib32-icu | grep Version

Which resulted in:

Version: 3.45.90-1
Version: 72.1-1
Version: 72.1-1
6

Oh, that is probably an AUR or chaotic-aur package that needs a rebuild.

1 Like
7

I have tried running the official gnome-terminal, same problem and remmina is an official repo package too, which has same problem exactly. But that icu is version 72, while gnome-terminal seems to require version 71? This could be the problem no?

8

Reinstalled the official gnome-terminal package and reran pacman -Qo gnome-terminal

Which resulted in the following.
/usr/bin/gnome-terminal is owned by gnome-terminal 3.44.1-1

9

That is a negative:

$ chaotic bump gnome-terminal-fedora
Package gnome-terminal-fedora not found in repo

@MrCaira you will have to update this package yourself, presumably with your AUR helper.

3 Likes
10

This does not matter..
As i mentioned further up I've since switched back to gnome-terminal from the official repos, and this error also occurs for remmina, which is also on the official repos, installed by garudas own setup tool.

$ pacman -Qi gnome-terminal
Name            : gnome-terminal
Version         : 3.44.1-1
Description     : The GNOME Terminal Emulator
Architecture    : x86_64
URL             : https://wiki.gnome.org/Apps/Terminal
Licenses        : GPL
Groups          : gnome
Provides        : None
Depends On      : vte3  gsettings-desktop-schemas
Optional Deps   : None
Required By     : None
Optional For    : garuda-libs  nautilus-admin-git  remmina
Conflicts With  : None
Replaces        : None
Installed Size  : 7,81 MiB
Packager        : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date      : 2022-05-28T19:26:02 CEST
Install Date    : 2022-10-23T21:18:03 CEST
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

$ pacman -Qo gnome-terminal remmina
/usr/bin/gnome-terminal is owned by gnome-terminal 3.44.1-1
/usr/bin/remmina is owned by remmina 1:1.4.27-1
$ pacman -Qi gnome-terminal remmina icu lib32-icu | grep Version

Version         : 3.44.1-1
Version         : 1:1.4.27-1
Version         : 72.1-1
Version         : 72.1-1
$ gnome-terminal
gnome-terminal: error while loading shared libraries: libicuuc.so.71: cannot open shared object file: No such file or directory
$ remmina
remmina: error while loading shared libraries: libicuuc.so.71: cannot open shared object file: No such file or directory

EDIT: I've also just now, tried to do a recovery in timeshift to before the update, and run it again through the system-updater tool build into Garuda-Assistant GUI.
And the problem is still there after this update.

12

This happens also on garuda KDE dr456onized with megasync after last update:
megasync: error while loading shared libraries: libicuuc.so.71: cannot open shared object file: No such file or directory

pacman -Qi megasync icu lib32-icu | grep Version
Version         : 4.6.8.0-1
Version         : 72.1-1
Version         : 72.1-1
1 Like
13

Then probably it is another library used by gnome-terminal. For example, which vte3 package are you using? Maybe that needs a rebuild?

That means your megasync package is still built against the old icu. Depending on where you got it from, it is either needs to be updated or rebuilt. If you got it from the megasync repo, you need to wait for them to update it.

14

The vte3 im using is also from the official repositoies.

$ sudo pacman -Qi vte3
Name            : vte3
Version         : 0.70.1-1
Description     : Virtual Terminal Emulator widget (GTK3)
Architecture    : x86_64
URL             : https://wiki.gnome.org/Apps/Terminal/VTE
Licenses        : LGPL
Groups          : None
Provides        : libvte-2.91.so=0-64
Depends On      : fribidi  gnutls  gtk3  pcre2  systemd  vte-common
Optional Deps   : None
Required By     : gnome-terminal  libpamac-aur  pamac-aur  remmina  timeshift
Optional For    : gedit-plugins
Conflicts With  : None
Replaces        : None
Installed Size  : 1090.64 KiB
Packager        : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Build Date      : Sat Oct 22 14:01:11 2022
Install Date    : Mon Oct 24 13:06:29 2022
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature


$ pacman -Qi gnome-terminal vte3 icu lib32-icu | grep Version
Version         : 3.44.1-1
Version         : 0.70.1-1
Version         : 72.1-1
Version         : 72.1-1

$ pacman -Qo vte3                             
error: No package owns vte3
15

Somewhere you have a package built against the old icu. I don't know which one it is. Take a look at all your AUR packages. check vte-common, etc

1 Like
16

Checked up on it, reinstalling the vte3 package. My gnome-terminal changed to instead tell me that the locale i was using was not supported. By gnome-terminal.. So had to uncomment
en_US.UTF-8 UTF-8 and run sudo locale-gen

This fixed my issue, but that is just annoying af. I was basically being punished for only using

da_DK.UTF-8 UTF-8
en_DK.UTF-8 UTF-8

But it all now works again..

17

Does the solution of checking vte-common, reinstalling vte3 and figgling around with locale-gen also applies for megasync?

Cuz waiting for someone to rebuild the package somewhere (it's available on a few repos) means that I am out of date of all packages on all my systems since over a week (megasync is a must to work on my systems) and no one knows how long it will take for that not so common package to get updated. :frowning: I do know that building it myself from AUR fails (even v4.7.1), but that's off topic here.

18

Does megasync from aur fail building due to this error ? There is a workaround apparently: git config --global protocol.file.allow

19

Yeah I tried that earlier and it sadly failed again. :frowning:
Although in the end I don’t want to build on every update, as it seems that’s how this package from AUR works. I think the package is in Chaotic too IIRC, although I have no idea if Chaotic can just rebuild and by magic it would work…

20

Update, it has been fixed by rebuiilding libpdfium-nojs

21

How do you know that?
I don't see updated packages on AUR (both megasync and megasync-bin), don't see new comments posted either.