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

From: dewu <[email-masked]>
Date: Sat, 1 Mar 2025 16:36:08 +0100

On 1.03.2025 03:35, Stefan Kangas wrote:
> Corwin Brust <[email-masked]> writes:
>
>> On Thu, May 2, 2024, 10:50 Eli Zaretskii <[email-masked]> wrote:
>>
>>   > Date: Thu, 02 May 2024 08:01:58 +0200
>>   > From: Dewu <[email-masked]>
>>   >
>>   > 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
> Is there more to do here, or should this be closed?
The new Windows binaries for 30.1 no longer seem to suffer from this issue.