v3.2.9 tagged

[Vadim Zeitlin]

Hello,

I've added a last bunch of fixes/backports to 3.2 and tagged the current
version of the branch as v3.2.9 and created the draft release corresponding
to it. As usual, the link only accessible to the members of wx organization
on GitHub:

https://github.com/wxWidgets/wxWidgets/releases/tag/untagged-1ec231a9cce7888fa34c

Please let me know if anybody sees any problems with the source archives
and/or if there are any issues with building the binaries from them.

As you can see, I've fixed the official release date to 2025-12-12, which
leaves a few days for testing, so please do test it if you can.

Thanks in advance,
VZ

[Danny Scott]

I'm still building, but so far the only reported problem is with vc14x

cl /c /nologo /TC /Fovc14x_x64_mswudll\wxregex_pcre2_auto_possess.obj /MD /DWIN32  /Zi /Fd..\..\lib\vc14x_x64_dll\wxregexu.pdb   /O2 /D_CRT_SECURE_NO_DEPRECATE=1  /D_CRT_NON_CONFORMING_SWPRINTFS=1 /D_SCL_SECURE_NO_WARNINGS=1  /D__NO_VC_CRTDBG__  /DNDEBUG  /D_CRT_SECURE_NO_WARNINGS /I..\..\include /I..\..\lib\vc14x_x64_dll\mswu  /I..\..\3rdparty\pcre\src\wx /D__WX__ /DHAVE_CONFIG_H /D_UNICODE    ..\..\3rdparty\pcre\src\pcre2_auto_possess.c
pcre2_auto_possess.c
C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt\wchar.h(316): error C2440: 'initializing': cannot convert from 'int' to '__m128i'

--

Danny Scott

[Vadim Zeitlin]

On Sun, 7 Dec 2025 11:18:36 -0400 Danny Scott wrote:

DS> I'm still building, but so far the only reported problem is with vc14x

Oops, this is not good news because this is, of course, the most important
toolset.

DS> cl /c /nologo /TC /Fovc14x_x64_mswudll\wxregex_pcre2_auto_possess.obj /MD
DS> /DWIN32 /Zi /Fd..\..\lib\vc14x_x64_dll\wxregexu.pdb /O2
DS> /D_CRT_SECURE_NO_DEPRECATE=1 /D_CRT_NON_CONFORMING_SWPRINTFS=1
DS> /D_SCL_SECURE_NO_WARNINGS=1 /D__NO_VC_CRTDBG__ /DNDEBUG
DS> /D_CRT_SECURE_NO_WARNINGS /I..\..\include /I..\..\lib\vc14x_x64_dll\mswu
DS> /I..\..\3rdparty\pcre\src\wx /D__WX__ /DHAVE_CONFIG_H /D_UNICODE
DS> ..\..\3rdparty\pcre\src\pcre2_auto_possess.c
DS> pcre2_auto_possess.c
DS> C:\Program Files (x86)\Windows
DS> Kits\10\include\10.0.26100.0\ucrt\wchar.h(316): error C2440:
DS> 'initializing': cannot convert from 'int' to '__m128i'

This seems familiar and I think it might be the same problem as here:

https://learn.microsoft.com/en-us/answers/questions/2262171/windows-sdk-10-0-26100-causes-compilation-error-in

i.e. due to a too recent (for MSVS 2015) platform SDK. Unfortunately I'm
not sure if it's possible to revert an SDK upgrade, but if it is, I'd try
to do it and hope that it fixes the problem.

Could you please show what is at/around the line 316 of wchar.h in this
version (I don't have it here)? Maybe we can find some workaround...

Thanks,
VZ

[Danny Scott]

I forgot that we went through this with the 3.3.1 release. I needed to add the 10.0.17763.0 specification at the end of the calls to vcvarsall.bat

I have added this and things appear to be going well. 

I will add the binaries today. I will prepare a PR someday later for a potential 3.2.10 release.

--

Danny Scott

[Danny Scott]

Everything went OK. Built from exe file. Uploaded, downloaded, checksums added.

[Vadim Zeitlin]

On Sun, 7 Dec 2025 12:59:07 -0400 Danny Scott wrote:

DS> Everything went OK. Built from exe file. Uploaded, downloaded, checksums
DS> added.

Thanks a lot!

There unfortunately was a very serious regression in v3.2.9 (#26020) and
also a less serious #26019. None of them affects wxMSW binaries per se, but
I've decided to change wxSUBRELEASE_NUMBER in wx/version.h from 0 to 1
because of these changes, which does affect them.

However, I think we can still keep the wxMSW binaries you've already
built: they will show version v3.2.9.0 and not v3.2.9.1, but does it really
matter knowing that the changes between them don't affect wxMSW
functionality in any way?

OTOH if it wouldn't be a huge effort for you to rebuild them once again,
it could be still better to do it just to avoid even thinking about this
question. Please let me know if you think you could rebuild them and I'll
launch v3.2.9.1 source archives generation right now in this case.

Sorry for all these problems!
VZ

[Danny Scott]

No problem. I can rebuild them before noon on Monday gmt-4. 

Danny

[Vadim Zeitlin]

On Sun, 7 Dec 2025 18:56:53 -0400 Danny Scott wrote:

DS> No problem. I can rebuild them before noon on Monday gmt-4.

I'm really sorry, but after thinking more about this, I think I've
convinced myself that we don't really need to redo them (at least if no
other problems affecting wxMSW are found): we just had v3.2.9 tag in the
repository, but 3.2.9 release hasn't been made public yet, so it doesn't
seem necessary to use a different version for the final release. And, if
so, we don't need to change the full version in wx/version.h and then there
are no changes affecting wxMSW binaries.

So for now I've deleted v3.2.9 tag and replaced it with v3.2.9-rc1 tag,
pointing at exactly the same commit. And I'll create the final v3.2.9 tag
tomorrow if no more problems are found with the latest 3.2 version.

Sorry again for confusion and bothering you needlessly, but, as of right
now, I don't think you need to do anything.

Thanks again,
VZ

[Xaviou]

Hi.

I'm starting the builds (sorry for the delay...)

I have 2 questions :

- do I still have to make the builds for the old compilers such as gcc-7.3/8.1/TDM10.3 ? And all version of gcc for msys (12.2/13.2/14.2/15.1) as msys comes now with gcc 15.2.0

- what about the 14.2.0 version for the official compiler that comes with Code::Blocks (https://github.com/wxWidgets/wxWidgets/issues/25651) : do I need to make special packages (named for example wxMSW-3.2.9_gcc1420_x64_UCRT_Dev.7z or something like this) ?

It is not a problem for me to make all these builds, but I'm not sure they will all be usefull.

Regards

Xav'

[Vadim Zeitlin]

On Mon, 8 Dec 2025 08:15:42 -0800 (PST) Xaviou wrote:

X> I'm starting the builds (sorry for the delay...)

No problem, we still have 3 more days!

X> I have 2 questions :
X> - do I still have to make the builds for the old compilers such as
X> gcc-7.3/8.1/TDM10.3 ? And all version of gcc for msys (12.2/13.2/14.2/15.1)
X> as msys comes now with gcc 15.2.0

If you look at the download statistics for 3.2.8 at

https://tooomm.github.io/github-release-stats/?username=wxWidgets&repository=wxWidgets

it seems like they're still being downloaded a lot, but I'm very sceptical
of these numbers because they seem very suspiciously homogeneous to me,
i.e. it seems difficult to believe that 7.3 dev archive was downloaded 9911
times, 8.1 one 10208 and 10.3TDM 9770 times — the numbers are just too
close to each other to be real, so I think there must be some automatic
(CI?) process somewhere downloading all of them regularly which accounts
for the bulk of them. However if this hypothesis is correct, it still looks
like ~1000 extra downloads for 8.1 archive which is pretty close to the
number for 15.1, so it may still make sense to build those. But it's really
up to you, I think.

X> - what about the 14.2.0 version for the official compiler that comes with
X> Code::Blocks (https://github.com/wxWidgets/wxWidgets/issues/25651) : do I
X> need to make special packages (named for example
X> wxMSW-3.2.9_gcc1420_x64_UCRT_Dev.7z or something like this) ?

Yes, we need to identify them somehow. Apparently the full string would be
llvm-19.1.7-w64ucrt which is too long (and I wonder what is llvm doing here
if it's a gcc release?), so using just "ucrt" is probably fine (I wouldn't
capitalize it, but it's hardly critical). Another possibility would be to
use "CB25.03" to indicate that these files are supposed to be used with
the default compiler of this IDE but I'm not sure if it's really a good
idea so I prefer to leave the burden^H^H^H^H^H^H honour of taking this
decision to you again. Just please let me know what will be used, as the
web site download page will need to be updated to account for the new
compiler.

Thanks!
VZ

[Xaviou]

Hi.

All MinGW builds are done (using the 3.2.9-rc1 git tag).

Archives tested, uploaded, SHA1 checksums updated and SHA256 checksums verified with the ones calculated by github.

And for the Code::Blocks official compiler, the official name "gcc1420UCRT" has been used for the build and for the archives names:

 - wxMSW-3.2.9_gcc1420UCRT_Dev.7z
 - wxMSW-3.2.9_gcc1420UCRT_ReleaseDLL.7z
 - wxMSW-3.2.9_gcc1420UCRT_x64_Dev.7z
 - wxMSW-3.2.9_gcc1420UCRT_x64_ReleaseDLL.7z

Regards

Xav'

[Vadim Zeitlin]

Hello again,

I'm sorry, but I'm afraid I've done something stupid: I've regenerated a
source release with the files changes since v3.2.9-rc1 (which don't affect
the binaries but do affect the source archives) and this has overwritten
the existing draft release. Luckily, this has preserved the binaries, so
they don't need to be reuploaded again, but it lost:

1. The check sums.
2. Any other changes to the release text.

I've restored the line about Winlibs gcc 14.2 binaries from memory, but I
don't know if either of you has done any other changes, could you please
redo them if you did?

And if you still have the checksums, could you please restore them as
well? I could download the files and compute the checksums myself, but this
wouldn't be much of a guarantee...

Sorry again!
VZ

[Danny Scott]

Will have them added shortly.

--

Danny Scott

[Danny Scott]

Checksums restored.

--

Danny Scott

[Xaviou]

As I've kept the checksums list, it wasn't hard to restore.

Regards

Xav'

[Vadim Zeitlin]

On Thu, 11 Dec 2025 12:42:41 -0800 (PST) Xaviou wrote:

X> As I've kept the checksums list, it wasn't hard to restore.

Great, I'll announce the release soon, thanks to both of you and sorry
again!

VZ