bug#22442: [PATCH] Fix compilation erorr when --enable-gcc-warnings passed

[Paul Eggert]

Alexander Kuleshov wrote:
> Even without it I can't reproduce this bug. I've checkout to the previous
> commit (035bd8159fe5bcea15eacc8a23ab54f4bc3b6f17) and configured and
> built emacs with:
>
> ./configure --enable-link-time-optimization --without-pop \
> --without-kerberos --without-kerberos5 --without-hesiod   \
> --with-sound=alsa --with-x-toolkit=gtk3 --with-xpm --with-jpeg \
> --with-tiff --with-gif --with-png --with-rsvg --with-cairo     \
> --with-xml2 --with-imagemagick --with-xft --without-libotf     \
> --with-xim --with-xaw3d --with-dbus --without-gconf            \
> --without-gsettings --without-selinux --with-gnutls --with-zlib \
> --with-modules --with-file-notification=inotify --without-makeinfo \
> --with-x && make
>
> Than I've opened image as you described in thehttp://bugs.gnu.org/22442
> and it works perfectly for me.

I tried the same scenario and I get a blank image on the screen. Perhaps it 
depends on the imagemagick or cairo version or whatever. I'm running Emacs on 
Fedora 23 x86-64, and displaying on Ubuntu 15.10 x86-64 via an ssh -X link.

If I use the current emacs-25 commit () but keep everything else the same, Emacs 
displays the binary text of the image with a message in the bottom line "Cannot 
display image: (This Emacs mishandles this image file type)", which is what I 
would expect from the current code. I don't know why I wasn't observing this 
behavior earlier, but at least now I know that Bug#22442 is still kicking.

As Mark says, Bug#22442 and Bug#21110 are probably the same bug, so I'll merge 
them. I can't recommend --with-cairo at this point.