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

Full log

View this message in rfc822 format

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: 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.