1

I run Parabola (a derivative of Arch Linux that blacklists non-free software and adds a lot of other software). Recently the ICU package updated from v.59 to v.60 (the ICU package comes directly from Arch's repositories, not from Parabola). As a result many of the packages from Parabola's own repositories needed to be rebuilt against the new version of ICU including both ring-client-gnome and california.

I've confirmed that on a fresh virtual machine both "gnome-ring" and "california" run without any issues. Other users on IRC report the same.

However, on my personal machine both "gnome-ring" and "california" fail to start. I've not been able to replicate this issue other than on an old virtual machine which has unfortunately been corrupted.

What's odd is that despite ring-client-gnome being built for ICU v60 mine seems to want v59 as well as v60. For example, if you uninstall ICU gnome-ring will output that it can't find "libicui18n.so.60" as expected. But if you do have ICU installed it will output that it can't find "libicui18n.so.59". This doesn't make any sense since it would be impossible to install two different ICU versions without conflicts so it would appear that something is wrong with my installation.

Interestingly, no matter whether you have ICU installed or not, "california" will always output that it cannot find "libicui18n.so.59", despite it being built for ICU v60.

With latest ICU package (60.1-1) installed:

[user@hostname ~]$ gnome-ring
gnome-ring: error while loading shared libraries: libicui18n.so.59: cannot open shared object file: No such file or directory

[user@hostname ~]$ california
california: error while loading shared libraries: libicui18n.so.59: cannot open shared object file: No such file or directory

With no ICU package installed (the california one is not a typo):

[user@hostname ~]$ gnome-ring
gnome-ring: error while loading shared libraries: libicui18n.so.60: cannot open shared object file: No such file or directory

[user@hostname ~]$ california
california: error while loading shared libraries: libicui18n.so.59: cannot open shared object file: No such file or directory

Some more useful outputs:

[user@hostname ~]$ ldd /usr/lib/libring.so /usr/lib/libring.so.0 /usr/lib/libring.so.0.0.0 /usr/lib/ring/dring /usr/bin/gnome-ring /usr/bin/ring.cx | grep icu

    libicuuc.so.60 => /usr/lib/libicuuc.so.60 (0x0000604eec817000)
    libicudata.so.60 => /usr/lib/libicudata.so.60 (0x0000604ee9dca000)
    libicuuc.so.60 => /usr/lib/libicuuc.so.60 (0x000069782c24c000)
    libicudata.so.60 => /usr/lib/libicudata.so.60 (0x00006978297ff000)
    libicuuc.so.60 => /usr/lib/libicuuc.so.60 (0x00006ea1e4d8a000)
    libicudata.so.60 => /usr/lib/libicudata.so.60 (0x00006ea1e233d000)
    libicuuc.so.60 => /usr/lib/libicuuc.so.60 (0x0000686de13da000)
    libicudata.so.60 => /usr/lib/libicudata.so.60 (0x0000686dde98d000)
    libicui18n.so.60 => /usr/lib/libicui18n.so.60 (0x0000603da97c4000)
    libicuuc.so.60 => /usr/lib/libicuuc.so.60 (0x0000603da940b000)
    libicui18n.so.59 => not found
    libicuuc.so.59 => not found
    libharfbuzz-icu.so.0 => /usr/lib/libharfbuzz-icu.so.0 (0x0000603da49ee000)
    libicuuc.so.59 => not found
    libicui18n.so.59 => not found
    libicudata.so.60 => /usr/lib/libicudata.so.60 (0x0000603d9f05a000)
    libicuuc.so.59 => not found
    libicui18n.so.59 => not found
    libicuuc.so.59 => not found

ICU version:

[user@hostname ~]$ sudo pacman -Q icu
icu 60.1-1

Contents of /usr/lib/icu:

[user@hostname icu]$ ls -l
total 12
drwxr-xr-x 1 root root 46 Nov 22 14:16 60.1
lrwxrwxrwx 1 root root  4 Nov 12 09:33 current -> 60.1
lrwxrwxrwx 1 root root 20 Nov 12 09:33 Makefile.inc -> current/Makefile.inc
lrwxrwxrwx 1 root root 19 Nov 12 09:33 pkgdata.inc -> current/pkgdata.inc

Contents of /lib/libicu

[alex@LibrebootT400 lib]$ ls -la libicu*
lrwxrwxrwx 1 root root       18 Nov 12 09:33 libicudata.so -> libicudata.so.60.1
lrwxrwxrwx 1 root root       18 Nov 12 09:33 libicudata.so.60 -> libicudata.so.60.1
-rwxr-xr-x 1 root root 26825368 Nov 12 09:33 libicudata.so.60.1
lrwxrwxrwx 1 root root       18 Nov 12 09:33 libicui18n.so -> libicui18n.so.60.1
lrwxrwxrwx 1 root root       18 Nov 12 09:33 libicui18n.so.60 -> libicui18n.so.60.1
-rwxr-xr-x 1 root root  2762816 Nov 12 09:33 libicui18n.so.60.1
lrwxrwxrwx 1 root root       16 Nov 12 09:33 libicuio.so -> libicuio.so.60.1
lrwxrwxrwx 1 root root       16 Nov 12 09:33 libicuio.so.60 -> libicuio.so.60.1
-rwxr-xr-x 1 root root    55056 Nov 12 09:33 libicuio.so.60.1
lrwxrwxrwx 1 root root       18 Nov 12 09:33 libicutest.so -> libicutest.so.60.1
lrwxrwxrwx 1 root root       18 Nov 12 09:33 libicutest.so.60 -> libicutest.so.60.1
-rwxr-xr-x 1 root root    64616 Nov 12 09:33 libicutest.so.60.1
lrwxrwxrwx 1 root root       16 Nov 12 09:33 libicutu.so -> libicutu.so.60.1
lrwxrwxrwx 1 root root       16 Nov 12 09:33 libicutu.so.60 -> libicutu.so.60.1
-rwxr-xr-x 1 root root   203288 Nov 12 09:33 libicutu.so.60.1
lrwxrwxrwx 1 root root       16 Nov 12 09:33 libicuuc.so -> libicuuc.so.60.1
lrwxrwxrwx 2 root root       16 Nov 12 09:33 libicuuc.so.59 -> libicuuc.so.60.1
lrwxrwxrwx 2 root root       16 Nov 12 09:33 libicuuc.so.60 -> libicuuc.so.60.1
-rwxr-xr-x 1 root root  1799952 Nov 12 09:33 libicuuc.so.60.1

2 Answers 2

0

Parabola has a special repository called "nonprism" which contains a number of hardened packages and generally enhances privacy. I had forgotten that I had it enabled for testing awhile back.

Disabling this repository fixed both gnome-ring and california which suggests that one of the nonprism packages is broken. Managed to narrow it down to a broken dependency which suggests that evolution-data-server is the culprit. Sure enough, there is nonprism/evolution-data-server which is two versions behind the normal packages.

nonprism/evolution-data-server is on the queue to be rebuilt now. If this fixes the issue I'll mark this question as solved.

-1

This worked for me:

sudo ln /usr/lib/libicuuc.so.60 /usr/lib/libicuuc.so.59

(Assuming you have your system on ICU v60. If you're on v59, you can probably symlink 59 to 60.)

3
  • This is always a terrible idea.
    – jasonwryan
    Nov 25, 2017 at 5:22
  • using version 60 instead of version 59 should not cause a problem, but the binary probably should not be linked against version 59 anyway.
    – Jasen
    Nov 25, 2017 at 5:43
  • Tested it on a virtual machine, doesn't work regardless of whether it is a terrible idea or not. Nov 25, 2017 at 11:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .