0.95.2 Fails to Load in Linux Mint 19.3, Cinnamon

[djcj]

Latest tarball (64 bit) and AppImage are working for me (Ubuntu 18.04).

[wgc214]

I downloaded the latest tgz file, unpacked it, and copied XnView and all files beneath to my home directory. It fails with exactly the same messages as I previously reported.

It seems that the problem comes from libfontconfig, QT 5.12 requires libfontconfig 1.13

Thanks. I cannot find libfontconfig 1.13 being available for Fedora 31. So I will stick with XnView 0.94. I did install the Windows version of 0.95 under Wine and it works quite well even with an obvious bit of a performance hit.

Cheers.

[jonathan_s]

I too am using Fedora 31 Cinnamon, but I've managed to get it working.

The problem is not that libfontconfig is not up-to-date. As far as I can see, there is no libfontconfig.so.1.13 - both Fedora 31 and Debian 10 (the latest of each) have libfontconfig.so.1.12.

The real problem is that the version of libfreetype in {xnview-dir}/lib is incompatible with Fedora's version of libfontconfig. There was no libfreetype previously, hence the problem now.

To work round this, go to the {xnview-dir}/lib in the command shell and:

1) Delete the libfreetype.so file and the libfreetype.so.6 soft-link.
rm libfreetype.so
rm libfreetype.so.6

2) Link to the Fedora system libfreetype.
ln -s /usr/lib64/libfreetype.so.6 libfreetype.so.6

3) Also necessary is this link in the same directory, since Fedora's filename differs slighly from what XnView expects.
ln -s /usr/lib64/libbz2.so.1 libbz2.so.1.0

[wgc214]

I too am using Fedora 31 Cinnamon, but I've managed to get it working.

The problem is not that libfontconfig is not up-to-date. As far as I can see, there is no libfontconfig.so.1.13 - both Fedora 31 and Debian 10 (the latest of each) have libfontconfig.so.1.12.

The real problem is that the version of libfreetype in {xnview-dir}/lib is incompatible with Fedora's version of libfontconfig. There was no libfreetype previously, hence the problem now.

To work round this, go to the {xnview-dir}/lib in the command shell and:

1) Delete the libfreetype.so file and the libfreetype.so.6 soft-link.
rm libfreetype.so
rm libfreetype.so.6

2) Link to the Fedora system libfreetype.
ln -s /usr/lib64/libfreetype.so.6 libfreetype.so.6

3) Also necessary is this link in the same directory, since Fedora's filename differs slighly from what XnView expects.
ln -s /usr/lib64/libbz2.so.1 libbz2.so.1.0

Thank you! With one exception this worked perfectly. I changed the final link to:
ln -s /usr/lib64/libbz2.so.1.0 libbz2.so.1

Thank you again!

[jonathan_s]

Hi wgc214

Glad it works.

Just as an aside, it looks like you've changed the libbz2 filename in your Fedora system from the correct /usr/lib64/libbz2.so.1 to /usr/lib64/libbz2.so.1.0

My guess is that you've changed it in the past to make a previous version of XnView work, since it requires the name libbz2.so.1.0

You can check that Fedora should have libbz2.so.1 (rather than libbz2.so.1.0) in /usr/lib64 by looking at the files in the bzip2 rpm:
rpm -ql bzip2-libs-1.0.8-1.fc31.x86_64
/usr/lib/.build-id
/usr/lib/.build-id/6a
/usr/lib/.build-id/6a/f092b34798e4bb8225caa49302d1001fcea68e
/usr/lib64/libbz2.so.1
/usr/lib64/libbz2.so.1.0.8
/usr/share/licenses/bzip2-libs
/usr/share/licenses/bzip2-libs/LICENSE

With libbz2.so.1.0 in /usr/lib64, you won't need that link in (3) to make XnView work (XnView will find the filename it wants in that system directory, and the link you've made instead will make no difference). However any software from Fedora repositories trying to use that library will break, as the filename in /usr/lib64 is not what's expected.

The best solution is to change the name in /usr/lib64 to the correct one (/usr/lib64/libbz2.so.1) and put the link in (3) in the {xnview-dir}/lib, which will mean that all software will get the library-name it expects.


To the maintainer
-----------------

Debian and its derivatives appear to accept both libbz2.so.1 and libbz2.so.1.0
( See https://packages.debian.org/buster/amd6 ... 0/filelist )
Is there a reason for getting XnView to use libbz2.so.1.0 rather than libbz2.so.1 ?
I've checked Fedora and Ubuntu and virtually all libraries have just the one major version number after .so
That makes libbz2.so.1.0 an irregular library-name.

This is only a nitpick - I'm really happy with XnView and grateful for all your work on it. Thanks!

[wgc214]

Hi wgc214

Glad it works.

Just as an aside, it looks like you've changed the libbz2 filename in your Fedora system from the correct /usr/lib64/libbz2.so.1 to /usr/lib64/libbz2.so.1.0

My guess is that you've changed it in the past to make a previous version of XnView work, since it requires the name libbz2.so.1.0

You can check that Fedora should have libbz2.so.1 (rather than libbz2.so.1.0) in /usr/lib64 by looking at the files in the bzip2 rpm:
rpm -ql bzip2-libs-1.0.8-1.fc31.x86_64
/usr/lib/.build-id
/usr/lib/.build-id/6a
/usr/lib/.build-id/6a/f092b34798e4bb8225caa49302d1001fcea68e
/usr/lib64/libbz2.so.1
/usr/lib64/libbz2.so.1.0.8
/usr/share/licenses/bzip2-libs
/usr/share/licenses/bzip2-libs/LICENSE

With libbz2.so.1.0 in /usr/lib64, you won't need that link in (3) to make XnView work (XnView will find the filename it wants in that system directory, and the link you've made instead will make no difference). However any software from Fedora repositories trying to use that library will break, as the filename in /usr/lib64 is not what's expected.

The best solution is to change the name in /usr/lib64 to the correct one (/usr/lib64/libbz2.so.1) and put the link in (3) in the {xnview-dir}/lib, which will mean that all software will get the library-name it expects.

Hi jonathan_s:

Thanks again for your work to fix this issue. I did apply a fix for version .92. Here are my notes including your fix:

Base fix for XnViewMP 0.92+:
# cd /usr/lib64
# ln -s libzz2.so.1.0.6 libbz2.so.1.0
# ll *libbz*
lrwxrwxrwx 1 root root 15 Feb 6 2018 libbz2.so.1 -> libbz2.so.1.0.6
lrwxrwxrwx 1 root root 15 Sep 21 09:04 libbz2.so.1.0 -> libbz2.so.1.0.6
-rwxr-xr-x 1 root root 74360 Feb 6 2018 libbz2.so.1.0.6

After updating system to Fedora 31:
# cd /usr/lib64
# ls -l *libbz2*
lrwxrwxrwx 1 root root 15 Aug 6 2019 libbz2.so.1 -> libbz2.so.1.0.8
-rwxr-xr-x 2 root root 81584 Aug 6 2019 libbz2.so.1.0
-rwxr-xr-x 2 root root 81584 Aug 6 2019 libbz2.so.1.0.8

Additional fix for XnViewMP 0.95:
$ cd ~/XnView/lib
$ rm libfreetype.so.6 libfreetype.so
$ ln -s /usr/lib64/libfreetype.so.6 libfreetype.so.6

[xnview]

The real problem is that the version of libfreetype in {xnview-dir}/lib is incompatible with Fedora's version of libfontconfig. There was no libfreetype previously, hence the problem now.

yes, needed for other distribution such Ubuntu

2) Link to the Fedora system libfreetype.
ln -s /usr/lib64/libfreetype.so.6 libfreetype.so.6

This is not needed...

3) Also necessary is this link in the same directory, since Fedora's filename differs slighly from what XnView expects.
ln -s /usr/lib64/libbz2.so.1 libbz2.so.1.0

In previous version, libQt5XcbQpa use libbz2.so.1 too

[jonathan_s]

Hi xnview

Thanks for the reply.

Yes, I realized already that the link to libfreetype.so.6 was unnecessary - if XnView doesn't find libfreetype.so.6 in Xnview/lib, it'll just follow the library path and find the /usr/lib64 library with that name. All that's needed is to delete the link in XnView/lib - deleting libfreetype.so won't hurt but isn't strictly necessary as it will never get accessed without the link.

So all that's needed is:

Change directory to XnView/lib
ln -s /usr/lib64/libbz2.so.1 libbz2.so.1.0
rm libfreetype.so.6

-----------------------

I've done an 'ldd' on XnView itself and on all the libraries in XnView/lib (ldd lib*.so.* |less).
All of them use libbz2.so.1 EXCEPT libavformat.so.58, which wants libbz2.so.1.0
So it's not libQt5XcbQpa that's the problem but libavformat.
Any chance you could change libavformat to request libbz2.so.1 ? Debian, Ubuntu, etc will be fine as all the other libraries use libbz2.so.1 anyway.

Here's the (partial) output showing the problem:
ldd libavformat.so.58
linux-vdso.so.1 (0x00007fffa1b82000)
libavcodec.so.58 => /lib64/libavcodec.so.58 (0x00007fb35cb57000)
libavutil.so.56 => /lib64/libavutil.so.56 (0x00007fb35ca4c000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb35c906000)
libbz2.so.1.0 => not found
libz.so.1 => /lib64/libz.so.1 (0x00007fb35c8ec000)
...............
...............

Thanks again for your work on XnView - it's appreciated.

[xnview]

All of them use libbz2.so.1 EXCEPT libavformat.so.58, which wants libbz2.so.1.0
So it's not libQt5XcbQpa that's the problem but libavformat.

Right, sorry. But it was the same in previous version

[dma_k]

Does anybody have a receipt for Debian Linux x64? I have followed the advise above, namely:

Code: Select all

root@debian:/opt/XnView/lib # ln -s /usr/lib/x86_64-linux-gnu/libbz2.so.1.0
root@debian:/opt/XnView/lib # rm libfreetype.so*
root@debian:/opt/XnView/lib # ll libbz*
lrwxrwxrwx 1 root root 39 May 19 11:42 libbz2.so.1.0 -> /usr/lib/x86_64-linux-gnu/libbz2.so.1.0
root@debian:/opt/XnView/lib # ll libfreetype.so*
ls: cannot access 'libfreetype.so*': No such file or directory

but still XnView v0.96.2 does not start:

Code: Select all

$ xnview 
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Aborted (core dumped)

Symlinking libfreetype.so.6 as suggested here does not help.

I have one missing library though:

Code: Select all

root@debian:/opt/XnView/lib # LD_LIBRARY_PATH=. ldd lib*.so.* 2>&1 | grep 'not found' | sort -u
        libxkbcommon-x11.so.0 => not found

XnView v0.94.3 was the last version that works fine for me.

[xnview]

Does anybody have a receipt for Debian Linux x64? I have followed the advise above, namely:

which Debian?

[dma_k]

Debian Buster v10.3. I have further removed sylink for libbz2.so.1.0 because it does not play any role. Also note that I have libfontconfig so v1.12 (it was mentioned that 1.13 is required?)

Code: Select all

# LD_LIBRARY_PATH=. ldd lib*.so.* 2>&1 | egrep -o 'lib(bz2|freetype)[^(]+' | sort -u
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6

# ll /lib/x86_64-linux-gnu/lib{freetype,fontconfig}.so.*
lrwxrwxrwx 1 root root     23 Nov  5  2018 /lib/x86_64-linux-gnu/libfontconfig.so.1 -> libfontconfig.so.1.12.0
-rw-r--r-- 1 root root 281592 Nov  5  2018 /lib/x86_64-linux-gnu/libfontconfig.so.1.12.0
lrwxrwxrwx 1 root root     21 Jul 27  2019 /lib/x86_64-linux-gnu/libfreetype.so.6 -> libfreetype.so.6.16.1
-rw-r--r-- 1 root root 763816 Jul 27  2019 /lib/x86_64-linux-gnu/libfreetype.so.6.16.1

[xnview]

Debian Buster v10.3. I have further removed sylink for libbz2.so.1.0 because it does not play any role. Also note that I have libfontconfig so v1.12 (it was mentioned that 1.13 is necessary?)

could you try to remove platformthemes/libqgtk3.so?

[dma_k]

could you try to remove platformthemes/libqgtk3.so?

I removed it, but there is no effect. It breaks very quickly, the only library it loads is:

Code: Select all

$ strace xnview 2>&1 | egrep 'lib.*\.so\.'
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3

[xnview]

could you try to set

Code: Select all

export QT_DEBUG_PLUGINS=1

before to start it?