GNU bug report logs - #70713
29.3; Official Windows build - RSVG is either using an outdated version of the library or SVG support is not compiled correctly

Previous Next

To reply to this bug, email your comments to 70713 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dewu <dewu <at> tfwno.gf>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.3; Official Windows build - RSVG is either using an outdated
 version of the library or SVG support is not compiled correctly
Date: Thu, 02 May 2024 08:01:58 +0200

SVG (RSVG) support appears broken on the official Windows builds of GNU
Emacs.
This appears most prominently in osm (osm.el) by minad, available both 
on GNU
ELPA and MELPA, which uses SVG to display map tiles and location pins in 
the
buffer.
The tiles with pins under them appear to be blank, regardless of zoom
levels or tile set used.

The issue had been known to the developer of osm.el, as it was 
previously
reported on both Windows and macOS:
- https://github.com/minad/osm/issues/23
- https://github.com/minad/osm/issues/40
The conclusion was that both builds of Emacs lacked proper SVG support 
to display the tiles correctly.

This does not happen on any versions of Emacs built for GNU/Linux
available in official repositories or Flatpak.

I suspect that Emacs for Windows is either not built correctly with RSVG 
support, or
the library it is built against is too old (librsvg-2-2.dll).
This does not happen in Emacs built by MSYS2 (mingw-w64-x86_64-emacs) 
which
appears to be using a newer version of librsvg
(mingw-w64-x86_64-librsvg 2.58.0-1)

To replicate:
- emacs -Q
- acquire osm (GitHub, ELPA, or MELPA)
- load it (manually, autoloads, use-package etc.)
- M-x osm RET
- navigate the map
- click on the map, add boomarks etc.
- map tiles with pins under them appears blank


In GNU Emacs 29.3 (build 2, x86_64-w64-mingw32) of 2024-03-24 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.4291)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-sqlite3 --with-tree-sitter
 CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: PLK
  locale-coding-system: cp1250

Major mode: Osm

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util time-date mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils mule-util format-spec url-util url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars osm dom bookmark
text-property-search pp compat compat-autoloads osm-autoloads thingatpt
cl-loaddefs cl-lib find-func rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
w32notify w32 lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 78366 12110)
 (symbols 48 7186 0)
 (strings 32 23222 1764)
 (string-bytes 1 670931)
 (vectors 16 15482)
 (vector-slots 8 344174 16638)
 (floats 8 128 293)
 (intervals 56 420 1)
 (buffers 984 12))

Message #8 received at 70713 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dewu <dewu <at> tfwno.gf>, Corwin Brust <corwin <at> bru.st>
Cc: 70713 <at> debbugs.gnu.org
Subject: Re: bug#70713: 29.3;
 Official Windows build - RSVG is either using an outdated version of
 the library or SVG support is not compiled correctly
Date: Thu, 02 May 2024 17:50:43 +0300

> Date: Thu, 02 May 2024 08:01:58 +0200
> From: Dewu <dewu <at> tfwno.gf>
> 
> SVG (RSVG) support appears broken on the official Windows builds of GNU
> Emacs.
> This appears most prominently in osm (osm.el) by minad, available both 
> on GNU
> ELPA and MELPA, which uses SVG to display map tiles and location pins in 
> the
> buffer.
> The tiles with pins under them appear to be blank, regardless of zoom
> levels or tile set used.
> 
> The issue had been known to the developer of osm.el, as it was 
> previously
> reported on both Windows and macOS:
> - https://github.com/minad/osm/issues/23
> - https://github.com/minad/osm/issues/40
> The conclusion was that both builds of Emacs lacked proper SVG support 
> to display the tiles correctly.
> 
> This does not happen on any versions of Emacs built for GNU/Linux
> available in official repositories or Flatpak.
> 
> I suspect that Emacs for Windows is either not built correctly with RSVG 
> support, or
> the library it is built against is too old (librsvg-2-2.dll).
> This does not happen in Emacs built by MSYS2 (mingw-w64-x86_64-emacs) 
> which
> appears to be using a newer version of librsvg
> (mingw-w64-x86_64-librsvg 2.58.0-1)
> 
> To replicate:
> - emacs -Q
> - acquire osm (GitHub, ELPA, or MELPA)
> - load it (manually, autoloads, use-package etc.)
> - M-x osm RET
> - navigate the map
> - click on the map, add boomarks etc.
> - map tiles with pins under them appears blank

You seem to be talking about some binaries built from the source
tarball.  The Emacs project doesn't produce any binaries, it only
produces source tarballs.  If you downloaded the Windows binaries from
the GNU FTP site, then the volunteer who prepares them (CC'ed) might
be able to do something with that.  But in any case, there's no Emacs
bug here, per se, since what version of librsvg is being used to build
Emacs is not under our control.

In addition, I would like to point out that latest versions of librsvg
switched to Rust as the implementation language, which makes the
library less widely available.  For this reason, Lisp packages should
IMO not depend on features in these newer versions, if they want to be
compatible to as many systems as possible.

Message #11 received at 70713 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dewu <dewu <at> tfwno.gf>, 70713 <at> debbugs.gnu.org
Subject: Re: bug#70713: 29.3; Official Windows build - RSVG is either using an
 outdated version of the library or SVG support is not compiled
 correctly
Date: Sat, 4 May 2024 22:02:48 -0400

[Message part 1 (text/plain, inline)]

On Thu, May 2, 2024, 10:50 Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Thu, 02 May 2024 08:01:58 +0200
> > From: Dewu <dewu <at> tfwno.gf>
> >
> > I suspect that Emacs for Windows is either not built correctly with RSVG
> > support, or
> > the library it is built against is too old (librsvg-2-2.dll).
> > This does not happen in Emacs built by MSYS2 (mingw-w64-x86_64-emacs)
> > which
> > appears to be using a newer version of librsvg
> > (mingw-w64-x86_64-librsvg 2.58.0-1)
>

I am traveling and cannot double check but I am fairly sure the feature
test for rsvg passed for the 29.3 set published. If you get t from
evaluating this elisp then I would assume the packages you mentioned need a
newer RSVG DLL:

(image-type-available-p 'svg)

So far, I do not take new versions of DLLs used to compile Emacs for
Windows except when releasing a new major version. So, according to my
intentions, I will take the latest available stable version for RSVG -and
GCC, and everything else- at the point we have an Emacs 30 pre-test (or
hint of impending pre-test, probably).

I think this reduces the likelihood of someone being unable to use the
no-deps binary distributable due to having to old of a version, the more so
the longer one waits into the given major version release cycle. By 29.3 it
seems very unlikely someone still has an older RSVG than we provide that
the want to keep.

That unpacked, I'm open to discussions. Perhaps some constituent DLLs
should be updated more aggressively; this could be worable given I can
clearly understand when to update what. Alternately, someone might take up
the position we should always use the latest versions of everything,
including for point releases, or based in intervening time passing or
number of upstream releases since new dep/dep-source archives have been
created.

The current process is simple for me and seems to cater to people who want
maximum stability, but it is hardly set in stone.


Thanks for reporting!
Corwin

>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.