gdk-pixbuf2 2.32.1-1 with librsvg 2.40.10-1: "Couldn't recognize the image file format for file" error for SVG files

achadwick commented 8 years ago

When MyPaint tries to load an icon for its initial runtime test, I get:

ERROR: gui.application: Missing icon 'mypaint-brush-symbolic': check that librsvg is installed, and update loaders.cache
Traceback (most recent call last):
  File "./gui/application.py", line 126, in _init_icons
    pixbuf = icon_theme.load_icon(icon_name, 32, 0)
Error: gtk-icon-theme-error-quark: Icon 'mypaint-brush-symbolic' not present in theme Adwaita (0)
CRITICAL: gui.application: Required icon(s) missing
ERROR: gui.application: Icon search path: ['C:\\Users\\Test User\\AppData\\Local\\icons', 'C:\\msys64\\home\\Test User\\.icons', 'C:\\ProgramData\\icons', 'C:\\Users\\Public\\Documents\\icons', 'C:\\msys64\\mingw64\\share\\icons', 'C:\\msys64\\mingw64\\share\\icons', 'C:\\msys64\\mingw64\\share\\icons', 'C:\\ProgramData\\pixmaps', 'C:\\Users\\Public\\Documents\\pixmaps', 'C:\\msys64\\mingw64\\share\\pixmaps', 'C:\\msys64\\mingw64\\share\\pixmaps', 'C:\\msys64\\mingw64\\share\\pixmaps', 'desktop/icons']
ERROR: gui.application: Mypaint can't run sensibly without its icons; please check your installation. See https://gna.org/bugs/?18460 for possible solutions.

which is not normal: the desktop/icons icon search path in particular is correct and accessible. Investigating further, I see that it's the gdkpixbuf/librsvg interface breaking again:

$ python -i
Python 2.7.10 (default, Jul  8 2015, 15:10:39)
[GCC 5.1.0] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import gi
>>> gi.require_version('GdkPixbuf', '2.0')
>>> from gi.repository import GdkPixbuf
>>> f = 'desktop/icons/hicolor/scalable/actions/mypaint-brush-symbolic.svg'
>>> import os
>>> os.stat(f)
nt.stat_result(st_mode=33206, st_ino=0L, st_dev=0L, st_nlink=0, st_uid=0, st_gid=0, st_size=3413L, st_atime=1444448745L, st_mtime=1424809209L, st_ctime=1424814029L)
>>> os.access(f, os.R_OK)
True
>>> GdkPixbuf.Pixbuf.new_from_file(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
GLib.Error: gdk-pixbuf-error-quark: Couldn't recognize the image file format for file 'desktop/icons/hicolor/scalable/actions/mypaint-brush-symbolic.svg' (3)
>>> GdkPixbuf.Pixbuf.new_from_file_utf8(unicode(f))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
GLib.Error: gdk-pixbuf-error-quark: Couldn't recognize the image file format for file 'desktop/icons/hicolor/scalable/actions/mypaint-brush-symbolic.svg' (3)
>>> quit()

I have everything installed that should be needed:

$ pacman -Ss rsvg
mingw32/mingw-w64-i686-librsvg 2.40.10-1 [installed]
    A SVG viewing library (mingw-w64)
mingw64/mingw-w64-x86_64-librsvg 2.40.10-1 [installed]
    A SVG viewing library (mingw-w64)

$ pacman -Ss gdk
mingw32/mingw-w64-i686-gdk-pixbuf2 2.32.1-1 [installed]
    An image loading library (mingw-w64)
mingw64/mingw-w64-x86_64-gdk-pixbuf2 2.32.1-1 [installed]
    An image loading library (mingw-w64)

$ pacman -Ss gtk3
mingw32/mingw-w64-i686-gtk-engine-unico 1.0.2-2
    Unico GTK3 theme engine
mingw32/mingw-w64-i686-gtk3 3.18.1-1 [installed]
    GObject-based multi-platform GUI toolkit (v3) (mingw-w64)
mingw32/mingw-w64-i686-gtkmm3 3.18.0-1
    C++ bindings for gtk3 (mingw-w64)
mingw32/mingw-w64-i686-spice-gtk 0.29-1
    GTK3 widget for SPICE clients (mingw-w64)
mingw32/mingw-w64-i686-webkitgtk3 2.4.9-1
    GTK+ Web content engine library (mingw-w64)
mingw64/mingw-w64-x86_64-gtk-engine-unico 1.0.2-2
    Unico GTK3 theme engine
mingw64/mingw-w64-x86_64-gtk3 3.18.1-1 [installed]
    GObject-based multi-platform GUI toolkit (v3) (mingw-w64)
mingw64/mingw-w64-x86_64-gtkmm3 3.18.0-1
    C++ bindings for gtk3 (mingw-w64)
mingw64/mingw-w64-x86_64-spice-gtk 0.29-1
    GTK3 widget for SPICE clients (mingw-w64)
mingw64/mingw-w64-x86_64-webkitgtk3 2.4.9-1
    GTK+ Web content engine library (mingw-w64)

and I've tried reinstalling librsvg and gdk-pixbuf2 several times.

achadwick commented 8 years ago

/mingw64/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache:

# GdkPixbuf Image Loader Modules file
# Automatically generated file, do not edit
# Created by gdk-pixbuf-query-loaders.exe from gdk-pixbuf-2.32.1
#
# LoaderDir = C:\msys64\mingw64/lib/gdk-pixbuf-2.0/2.10.0/loaders
#
"C:/msys64/mingw64/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.dll"
"svg" 6 "gdk-pixbuf" "Scalable Vector Graphics" "LGPL"
"image/svg+xml" "image/svg" "image/svg-xml" "image/vnd.adobe.svg+xml" "text/xml-svg" "image/svg+xml-compressed" ""
"svg" "svgz" "svg.gz" ""
" <svg" "*    " 100
" <!DOCTYPE svg" "*             " 100

$ ls -l 'C:/msys64/mingw64/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.dll'
-rwxr-xr-x 1 Test User None 20608 Aug 17 17:29 C:/msys64/mingw64/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.dll
$ file 'C:/msys64/mingw64/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.dll'
C:/msys64/mingw64/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.dll: PE32+ executable (DLL) (console) x86-64 (stripped to external PDB), for MS Windows

DavidEGrayson commented 8 years ago

I don't know anything about these libraries. But it sounds like you want gdk-pixbuf2 to use rsvg to parse an SVG icon. The PKGBUILD does not mention SVG support or a dependency on rsvg though:

https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gdk-pixbuf2/PKGBUILD

Is it possible that SVG support needs to be enabled at build time?

achadwick commented 8 years ago

@DavidEGrayson It loads it via a module, and loaders.cache is supposed to tell gdk-pixbuf2 what .so or .dll to link at runtime to provide support for the identified image type.

Think of librsvg support as an add-on to gdk-pixbuf2 for this use - an add-on that's required by GTK/GNOME stuff due to the heavy reliance on symbolic icons.

achadwick commented 8 years ago

Rewinding to gtk-pixbuf2 2.32.0-1 via http://repo.msys2.org/mingw/x86_64/ (thank you again to whoever keeps old versions there!) alone demonstrates that this is introduced by mingw-w64-x86_64-gdk-pixbuf2-2.32.1-1-any.pkg.tar.xz, and the corresponding commit is 696b84d68a0717b48131504262843d2e921158e2.

That commit isn't too surprising, so this looks like an upstream issue. Paging @KrullKorg all the same... :grinning:

achadwick commented 8 years ago

I don't know what the commit that causes this is between 2.32.0 and 2.32.1 upstream yet, but the problem doubtless lies in there!

KrullBorg commented 8 years ago

Could you try with this?

http://saetta.ns0.it/video/mingw-w64-x86_64-gdk-pixbuf2-2.32.1-2-any.pkg.tar.xz http://saetta.ns0.it/video/PKGBUILD

it worked for me

achadwick commented 8 years ago

Suggested patch looks like

--- PKGBUILD.orig       2015-10-06 19:58:46.587709400 +0100
+++ PKGBUILD.saetta     2015-10-11 10:38:46.000000000 +0100
@@ -6,5 +6,5 @@
 pkgname="${MINGW_PACKAGE_PREFIX}-${_realname}"
 pkgver=2.32.1
-pkgrel=1
+pkgrel=2
 pkgdesc="An image loading library (mingw-w64)"
 arch=('any')
@@ -52,5 +52,6 @@
     --enable-shared \
     --enable-introspection \
-    --with-included-loaders
+    --with-included-loaders \
+    --enable-relocations
   make
 }

I can confirm that:

a local rebuild with b4811486ef0bc98c94d07bdcd073d17f18bd7bc6's PKGBUILD,
a local build with http://saetta.ns0.it/video/PKGBUILD,
just installing http://saetta.ns0.it/video/mingw-w64-x86_64-gdk-pixbuf2-2.32.1-2-any.pkg.tar.xz,

all make the problem go away for me when I build/install from the /usr/src tree. This doesn't confirm that --enable-relocations will fix this bug, but it does confirm that the current build is broken, and that --enable-relocations isn't harmful.

(Sorry for the slightly inconclusive test!)

achadwick commented 8 years ago

(It's probably a good idea to make a PR for it - it looks like the sort of thing that might fix this issue.)

KrullBorg commented 8 years ago

i think it's not a bug; simply before relocation wasn't optional but based on architecture

see https://git.gnome.org/browse/gdk-pixbuf/commit/?id=847f707477753876a0700b1decb2465b3c82506f

mingwandroid commented 8 years ago

I'm confused by this thread. To test relocatability, build in a temporary MSYS2 tree and install to your normal tree.

achadwick commented 8 years ago

The behaviour in the report is a regression of the binary package from 2.32.0-1 to 2.32.1-1, which is a bug to my mind.

(I'm surely not alone here, right? Are other people just not reproducing this one?)

achadwick commented 8 years ago

Okay, better test:

Install repo.msys2.org's 2.32.1-1 package under my usual prefix and test:
- pacman -Sy mingw-w64-x86_64-gdk-pixbuf2
- test script below
- result: FAIL: "GLib.Error: gdk-pixbuf-error-quark: Couldn't recognize the image file format for file 'mypaint-tool-hcywheel.svg' (3)"
Install https://msys2.github.io to the C: drive under a different prefix (C:_msys64tmp or something)
- Update it as described on the page
- Install base-devel and toolchains
- Clone MINGW-packages at d70162e731c0bd195c7fe0f8f79ae52ac6940d26 under its /usr/src
Build and test d70162e731c0bd195c7fe0f8f79ae52ac6940d26 unchanged in the temporary tree, then install under the usual tree
- pacman -U /c/_msys64tmp/usr/src/MINGW-packages/mingw-w64-gdk-pixbuf2/mingw-w64-x86_64-gdk-pixbuf2-2.32.1-1-any.pkg.tar.xz
- test script below
- result: FAIL: "GLib.Error: gdk-pixbuf-error-quark: Couldn't recognize the image file format for file 'mypaint-tool-hcywheel.svg' (3)"
Build and test d70162e731c0bd195c7fe0f8f79ae52ac6940d26 patched with --enable-relocations in the temporary tree, then install under the usual tree
- (procedure as above, patch used below)
- result: OK ("loaded <Pixbuf object at 0x2412640 (GdkPixbuf at 0x2afc720)> OK :)")

Test script

#!python

import gi
gi.require_version('GdkPixbuf', '2.0')
from gi.repository import GdkPixbuf
import sys
import os

def _attempt_load(filename):
    print "    stat() result: %r" % (os.stat(filename),)
    pixbuf = GdkPixbuf.Pixbuf.new_from_file(filename)
    print "    loaded %r OK :)" % (pixbuf,)

if __name__ == "__main__":
    for filename in sys.argv[1:]:
        print "+++ Attempting to load %r with GdkPixbuf" % (filename,)
        _attempt_load(filename)

Patch

diff --git a/mingw-w64-gdk-pixbuf2/PKGBUILD b/mingw-w64-gdk-pixbuf2/PKGBUILD
index 1b9d456..37d8582 100644
--- a/mingw-w64-gdk-pixbuf2/PKGBUILD
+++ b/mingw-w64-gdk-pixbuf2/PKGBUILD
@@ -51,6 +51,7 @@ build() {
     --enable-static \
     --enable-shared \
     --enable-introspection \
+    --enable-relocations \
     --with-included-loaders
   make
 }

mingwandroid commented 8 years ago

@achadwick can you make a pull request please?

achadwick commented 8 years ago

@mingwandroid Will do.

achadwick commented 8 years ago

(I've set @KrullKorg as author, as they had the insight and made the initial build)

achadwick commented 8 years ago

Thanks @Alexpux.

Of course that may just break anyone running a Python executable that lives outside the mingwXX tree as described in https://bugzilla.gnome.org/show_bug.cgi?id=755526 (for OSX Homebrew and Framework Python), but I imagine that's less common for anyone using MSYS2 to build apps for native Windows - I assume they'll ship their own python2w.exe like we do for MyPaint. Hopefully.

(Future me and anyone else: sorry if this breaks things later.)

msys2 / MINGW-packages

gdk-pixbuf2 2.32.1-1 with librsvg 2.40.10-1: "Couldn't recognize the image file format for file" error for SVG files #818

Test script

Patch