On Thu, May 2, 2024, 10:50 Eli Zaretskii <
eliz@gnu.org> wrote:
> Date: Thu, 02 May 2024 08:01:58 +0200
> From: Dewu <dewu@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