Arch Linux User Repository

I have created a new package: xnviewmp-system-libs. This is exactly the same build, except that the bundled Qt/icu libs are removed. Please try it if you want to use XnView without the bundled libs, and discuss any issue related to this configuration here: https://aur.archlinux.org/packages/xnviewmp-system-libs/. Do keep in mind that this is an experimental package though, and things may break when I try to fix other things...

If makepkg fails because the checksum is incorrect, please flag the package out-of-date and I will update the PKGBUILD.

The PKGBUILD now references the latest versioned archive, as a result of which it should keep working if a new version is released. However, upstream sometimes updates released archives in place, in which case the checksum will fail and a manual intervention is required.

Just FYI, won't have anything to do with the PKGBUILD: In order to get videos running I had to uninstall gstreamer-vaapi.

@indianahorst: I don't think the SSL errors have anything to do with the GPS map not working. I have just tried with xnviewmp-system-libs (my other package that uses the system Qt libs instead of the ones shipped with XnView), and I don't get those SSL errors, but the "No such signal GPSMapWidget::reloadMap()" error is still there and nothing shows up. Not sure what to do about this, you may want to report it on the forum.

XnView works fine, except the GPS Tab, which should show the coordinates of images.

When I start XnView from command line, I get this:

[code]

MyView::onLoaded ok

resetViewport (2cbbeb0) ==> 798 246 (369 246) 0 0

QObject::connect: No such signal GPSMapWidget::reloadMap() qt.network.ssl: QSslSocket: cannot resolve CRYPTO_num_locks qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_id_callback qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_locking_callback qt.network.ssl: QSslSocket: cannot resolve ERR_free_strings qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_cleanup qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_init qt.network.ssl: QSslSocket: cannot resolve sk_new_null qt.network.ssl: QSslSocket: cannot resolve sk_push qt.network.ssl: QSslSocket: cannot resolve sk_free qt.network.ssl: QSslSocket: cannot resolve sk_num qt.network.ssl: QSslSocket: cannot resolve sk_pop_free qt.network.ssl: QSslSocket: cannot resolve sk_value qt.network.ssl: QSslSocket: cannot resolve SSL_library_init qt.network.ssl: QSslSocket: cannot resolve SSL_load_error_strings qt.network.ssl: QSslSocket: cannot resolve SSL_get_ex_new_index qt.network.ssl: QSslSocket: cannot resolve SSLv3_client_method qt.network.ssl: QSslSocket: cannot resolve SSLv23_client_method qt.network.ssl: QSslSocket: cannot resolve SSLv3_server_method qt.network.ssl: QSslSocket: cannot resolve SSLv23_server_method qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get_chain qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf qt.network.ssl: QSslSocket: cannot resolve SSLeay qt.network.ssl: QSslSocket: cannot resolve SSLeay_version qt.network.ssl: QSslSocket: cannot call unresolved function SSLeay qt.network.ssl: Incompatible version of OpenSSL qt.network.ssl: QSslSocket: cannot call unresolved function SSLv23_client_method qt.network.ssl: QSslSocket: cannot call unresolved function SSL_library_init [/code]

It seems to have to to with different SSL versions, but I have OpenSSL 1.1 as well as OpenSSL 1.0 installed.

How can I force XnView to use the old OpenSSL 1.0?

@not_anonymous: thanks for the heads-up, but I don't think these warnings are very relevant and/or can be easily fixed.

xnviewmp E: Insecure RPATH '/home/pierre/Qt5.9.3/5.9.3/gcc_64/lib' in file ('opt/xnviewmp/XnView')

This is clearly not good, but this is how the application is compiled by the maintainer (remember, that's a binary package). I could hack things together using chrpath, but I don't think it's worth the hassle (and I'd rather avoid modifying prebuilt binaries).

xnviewmp E: Symlink (opt/xnviewmp/lib/libwebp.so.6) points to non-existing libwebp.so

I don't understand that one, libwebp.so definitely exists (in the same directory).

xnviewmp E: Dependency gtk3 detected and not included (libraries ['usr/lib/libgdk-3.so.0', 'usr/lib/libgtk-3.so.0'] needed in files ['opt/xnviewmp/lib/platformthemes/libqgtk3.so'])

The corresponding library in qt5-base also depends on libgtk-3.so, and qt5-base itself has an optdep on gtk3. Since this package already depends on qt5-base (indirectly), I don't think it's worth propagating the optdep.

from namcap run;

xnviewmp E: Insecure RPATH '/home/pierre/Qt5.9.3/5.9.3/gcc_64/lib' in file ('opt/xnviewmp/XnView')

xnviewmp E: Symlink (opt/xnviewmp/lib/libwebp.so.6) points to non-existing libwebp.so

xnviewmp E: Dependency gtk3 detected and not included (libraries ['usr/lib/libgdk-3.so.0', 'usr/lib/libgtk-3.so.0'] needed in files ['opt/xnviewmp/lib/platformthemes/libqgtk3.so'])

note there is now an AppImage provided as well for XnViewMP

0.88-1 has fixed the font issue.

0.88 is upon us :D This should solve the font issues, apparently fuan_k has already confirmed that :-) Don't forget to remove /opt/xnviewmp/lib/libfontconfig.so.1 if you used the hack I mentioned below.

@fuan_k: great news, and well done reporting these bugs! Looks like 0.88 is going to be a great release :-)

@Corax: he's doing this in private. Wait and see. edit: here is the bug tracker ticker: https://www.xnview.com/mantisbt/view.php?id=1315 I've also managed to get him to fix the broken config path I mentioned before (below). The problem was using the "Program (XnView)" setting during initial set up, instead of "User (System)". It was a bug anyway, now fixed too. https://www.xnview.com/mantisbt/view.php?id=1317