Tk804.036 widget.t test is failing with Strawberry Perl 5.4

[alanoflanagan]

When testing the Tk module with Strawberry Perl I am running into a test failure.
I have applied the recommended path to the module and it now builds fine but there is one test failure.

I built it using it because the normal Tk is has a problem when building Tk .
cpanm https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/download/patched_cpan_modules/Tk-804.036_001.tar.gz

\widget.t ................... 1/19
#   Failed test '$mw->pathname works'
#   at t\widget.t line 49.
#          got: 'window id "2820854" doesn't exist in this application at blib\lib\Tk\Widget.pm (autosplit into blib\lib\auto\Tk\Widget\pathname.al) line 1581.
# '
#     expected: ''

#   Failed test 'Pathname and pathname agree'
#   at t\widget.t line 50.
#          got: undef
#     expected: '.label'
# Looks like you failed 2 tests of 19.
t\widget.t ................... Dubious, test returned 2 (wstat 512, 0x200)

Has anyone seen this before or is it something that can be easily fixed because I don't want to force install without being sure.

[sisyphus]

Running

cpanm https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/download/patched_cpan_modules/Tk-804.036_001.tar.gz

works fine for me on StrawberryPerl-5.40.0.
Could you please provide the output you get from running perl -V

[alanoflanagan]

@sisyphus Thanks for the reply.
Its failing on 5.40.2.1
I have tested it on 5.38.2.2 and 5.40.0.1 [https://strawberryperl.com/releases.html] and it works fine.

C:\perl540>call portableshell.bat

Welcome to Strawberry Perl Portable Edition!

• URL - https://www.strawberryperl.com/
• See README.TXT for more info

---

Perl executable: C:\perl540\perl\bin\perl.exe
Perl version : v5.40.2 / MSWin32-x64-multi-thread

C:\perl540>perl -V
Summary of my perl5 (revision 5 version 40 subversion 2) configuration:

Platform:
osname=MSWin32
osvers=10.0.22631.5189
archname=MSWin32-x64-multi-thread
uname='Win32 strawberry-perl 5.40.2.1 # 05:42:50 Sun May 11 2025 x64'
config_args='undef'
hint=recommended
useposix=true
d_sigaction=undef
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=undef
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
Compiler:
cc='gcc'
ccflags ='-std=c99 -DWIN32 -DWIN64 -DPERL_TEXTMODE_SCRIPTS -DMULTIPLICITY -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO -fwrapv -fno-strict-aliasing -mms-bitfields'
optimize='-O2'
cppflags='-DWIN32'
ccversion=''
gccversion='13.2.0'
gccosandvers=''
intsize=4
longsize=4
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='long long'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='g++.exe'
ldflags ='-s -L"C:\perl540\perl\lib\CORE" -L"C:\perl540\c\lib"'
libpth=C:\perl540\c\lib C:\perl540\c\x86_64-w64-mingw32\lib C:\perl540\c\lib\gcc\x86_64-w64-mingw32\13.1.0
libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
libc=-lucrt
so=dll
useshrplib=true
libperl=libperl540.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs
dlext=xs.dll
d_dlsymun=undef
ccdlflags=' '
cccdlflags=' '
lddlflags='-mdll -s -L"C:\perl540\perl\lib\CORE" -L"C:\perl540\c\lib"'

Characteristics of this binary (from libperl):
Compile-time options:
HAS_LONG_DOUBLE
HAS_TIMES
HAVE_INTERP_INTERN
MULTIPLICITY
PERLIO_LAYERS
PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_SIPHASH13
PERL_HASH_USE_SBOX32
PERL_IMPLICIT_SYS
PERL_MALLOC_WRAP
PERL_OP_PARENT
PERL_PRESERVE_IVUV
PERL_USE_SAFE_PUTENV
USE_64_BIT_INT
USE_ITHREADS
USE_LARGE_FILES
USE_LOCALE
USE_LOCALE_COLLATE
USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC
USE_LOCALE_TIME
USE_PERLIO
USE_PERL_ATOF
USE_THREAD_SAFE_LOCALE
Built under MSWin32
Compiled at May 11 2025 15:48:20
@inc:
C:/perl540/perl/site/lib
C:/perl540/perl/vendor/lib
C:/perl540/perl/lib

C:\perl540>

[sisyphus]

Thanks - I see that issue with t/widget.t when building that version of Tk on that version (ie perl-5.40.2) of Strawberry Perl.
I'll try to work out why that particular version of perl is susceptible to that particular failure.

One thing I notice is that 5.40.0 sets $Config{optimize} to -Os -falign-functions -falign-jumps -falign-labels -falign-loops -freorder-blocks -freorder-blocks-algorithm=stc -freorder-blocks-and-partition, whereas 5.40.2 has it set to -O2.

Perhaps that's the problem.
@shawnlaffan, I know we thought that we could revert to -O2 but maybe Tk-804.036_001 does not handle that change ?
Anyway, I'll be back home tomorrow night and I can take a closer look at it then if this issue with Tk-804.036_001 is still not resolved.

[alanoflanagan]

@sisyphus I have also tested it on the newly release strawberry-perl-5.38.4.1-64bit-portable and it doesn't work on that either. Hopefully that might help you narrow the issue down.

[shawnlaffan]

It does indeed look like an optimisation problem. All tests pass when using perl Makefile.PL OPTIMIZE=-Os.

The OPTIMIZE setting can be controlled via cpanm using this invocation:

cpanm https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/download/patched_cpan_modules/Tk-804.036_001.tar.gz --configure-args="OPTIMIZE=-Os"

One could obviously add more of the flags used to build perl but I suspect (albeit without any evidence) they would not make much difference when running Tk.

[sisyphus]

Would you like a Tk-805.036_002.tar.gz that contains the following patch to the Makefile.PL :

--- Makefile.PL_orig	2024-05-04 08:31:34.000000000 +1000
+++ Makefile.PL	2025-06-19 21:46:25.657152800 +1000
@@ -40,10 +40,17 @@
 
 use Tk::MMutil;
 
+my $optimize = $Config{optimize};
+
 if ($IsWin32)
  {
   *MY::makeaperl = \&makeWin32perl;
   @libs = ('-lcomctl32 -limm32');
+  if($Config{cc} eq 'gcc')
+    {
+    $optimize = '-Os -falign-functions -falign-jumps -falign-labels -falign-loops -freorder-blocks -freorder-blocks-algorithm=stc -freorder-blocks-and-partition'
+      if $Config{gccversion} < 15;
+    }
  }
 else
  {
@@ -86,6 +93,7 @@
     'MYEXTLIB' => 'pTk/libpTk$(LIB_EXT)' . ($win_arch =~ /^(open32|pm)$/
 					    ? ' pTk/dllInit$(LIB_EXT)'
 					    : ''),
+    'OPTIMIZE' => $optimize,
     'LIBS'    => \@libs,
     'OBJECT'  => '$(O_FILES)',
     'PREREQ_PM'  => { 'Encode' => 0,

That should do the trick.
Of course, the Tk module has not yet been tested on a Windows perl using gcc-15.
And that testing probably won't happen until Strawberry Perl starts using gcc-15 - so there's a bit of speculation there, on my part.
But it works well with gcc-13, and I think (untested ?) it will also be needed with gcc-14.

Given the various vagaries of this approach you might prefer just to stick with your proposed cpanm solution ;-)
I think that would be fair enough - given that Strawberry Perl ships with cpanm.
The only advantages of using the patched Makefile.PL are that it will also work with cpan and that it doesn't require awareness of the need to use --configure-args=.. argument.

[shawnlaffan]

That patch looks good to me. I can build a new tarball using that.

If you have your gcc-15-built perl still lying around then it would be interesting to see if Tk builds with -O2.

[sisyphus]

I've always found building Tk on my own builds of perl to be very fickle, and my perl-5.41.13 (built with gcc-15.1.0) is no exception.
It's always much easier to build Tk on Strawberry Perl ;-)

I have managed to build Tk-804.036_001 on my build of perl-5.38.0 (built using gcc-13.1.0) - but it required that I append the c/include, c/lib and c/bin directories of my SP-5.38.2 installation to (respectively) the CPATH, LIBRARY_PATH and PATH environment variables.
(I think this was for the benefit of libpng and zlib only ... but I'm not sure.)

I then tried the same approach with my perl-5.40.0 (built using gcc-14.1.0) but that didn't work.
I got:

tixInputO.c:144:22: error: implicit declaration of function 'XCreateWindow'; did you mean 'CreateWindow'? [-Wimplicit-function-declaration]
  144 |     winPtr->window = XCreateWindow(winPtr->display,
      |                      ^~~~~~~~~~~~~
      |                      CreateWindow
gmake[1]: *** [makefile:895: tixInputO.o] Error 1
gmake[1]: Leaving directory 'D:/s/Tk-804.036_001/pTk'
make: *** [makefile:1659: pTk/libpTk.a] Error 2

IIRC, [-Wimplicit-function-declaration]warnings are fatal beginning with gcc-14.
So, I'll have to avoid that issue before proceeding further. (Something for the weekend.)

[sisyphus]

It gets a bit messy because some of the compilation warnings that are emitted have been turned into fatalities with gcc-14 and later.
(I employed the simple hack of suppressing those warnings in $Config{ccflags} when building with gcc-14 and gcc-15 ... crude, but effective.)
With gcc-15 it becomes necessary to ensure that we're using C17 or less. At C23 we get hammered by:

tkWinWm.c: In function 'MakeIconOrCursorFromResource':
tkWinWm.c:746:25: error: too many arguments to function 'pfnCreateIconFromResourceEx'; expected 0, have 7
  746 |         hIcon = (HICON) (pfnCreateIconFromResourceEx)
      |                         ^
  747 |         (lpIcon->lpBits, lpIcon->dwNumBytes, isIcon, 0x00030000,
      |          ~~~~~~~~~~~~~~ 

This issue could presumably be alternatively addressed by amending the code in tkWinWm.c, but my C capabilities are not up to that. (The same type of issue cropped up at Perl/perl5#23192 .)

Unfortunately, tests 6 and 7 of t/widget.t failed with gcc-15, irrespective of whether optimization was at -O2 or <code<-Os.

Anyway, here's the Makefile.PL patch that I used:

--- Makefile.PL_orig	2024-05-04 08:31:34.000000000 +1000
+++ Makefile.PL	2025-06-22 23:12:20.064078000 +1000
@@ -40,10 +40,27 @@
 
 use Tk::MMutil;
 
+my $optimize = $Config{optimize};
+my $flags = $Config{ccflags};
+
 if ($IsWin32)
  {
   *MY::makeaperl = \&makeWin32perl;
   @libs = ('-lcomctl32 -limm32');
+  if($Config{cc} eq 'gcc')
+    {
+    # Both gcc-14 and gcc-13 will fail tests 6 and 7 of t/widget.t if optimization is at -O2.
+    # With gcc-15, those 2 tests are failing for me, irrespective of whether optimization is at -O2 or -Os.
+    $optimize = '-Os-falign-functions -falign-jumps -falign-labels -falign-loops -freorder-blocks -freorder-blocks-algorithm=stc -freorder-blocks-and-partition'
+      if $Config{gccversion} < 15;
+
+    $flags .= " -Wno-implicit-int -Wno-incompatible-pointer-types -Wno-implicit-function-declaration -Wno-return-mismatch"
+      if $Config{gccversion} >= 14;       # Those warnings are now fatal.
+
+    $flags .= " -std=c17"
+      if $Config{gccversion} >= 15;       # Avoid error enabled by C23. This correction is not
+                                          # needed if existing CCFLAGS specifies C17 or earlier.
+    }
  }
 else
  {
@@ -86,6 +103,8 @@
     'MYEXTLIB' => 'pTk/libpTk$(LIB_EXT)' . ($win_arch =~ /^(open32|pm)$/
 					    ? ' pTk/dllInit$(LIB_EXT)'
 					    : ''),
+    'CCFLAGS'  => $flags,
+    'OPTIMIZE' => $optimize,
     'LIBS'    => \@libs,
     'OBJECT'  => '$(O_FILES)',
     'PREREQ_PM'  => { 'Encode' => 0,

Another issue (which I didn't really investigate) was that the pTk/tkConfig.h produced by gcc-13 differed from the pTk/tkConfig.h produced by gcc-14. (The one produced by gcc-14 was wrong.)
So I just hacked the top level myConfig file to force the correct rendition:

--- myConfig_orig	2024-05-04 08:31:37.000000000 +1000
+++ myConfig	2025-06-22 20:57:47.274518100 +1000
@@ -198,7 +198,7 @@
   $define{'HAS_PMOP_EXTRA_FLAGS'} = 1;
  }
 
-if (try_compile("config/pregcomp2.c",  ["-I$Config{'archlibexp'}/CORE"], undef, ["-c"]))
+if (1) # (try_compile("config/pregcomp2.c",  ["-I$Config{'archlibexp'}/CORE"], undef, ["-c"]))
  {
   $define{'USE_PREGCOMP_31027'} = 1; # pregcomp after perl change 31027
  }
@@ -208,7 +208,7 @@
   $define{'USE_REGEXP_511'} = 1; # REGEXP in perl 5.11.x
  }
 
-if (try_compile("config/signedchar.c"))
+if (1) # (try_compile("config/signedchar.c"))
  {
   $define{'ANSI_SIGNED_CHAR'} = 1;
  }

Again, crude but effective.

With all three perls (my perl-5.38.0 built using gcc-13.1.0, my perl-5.40.0 built using gcc-14.1.0, and my perl-5.41.13 built using gcc-15.1.0) I had to access c/bin, c/include, and c/lib from Strawberry Perl 5.40.2.1 in order to build Tk.
I added that "bin" folder to the end of the PATH envvar, added that "include" folder to the end of my CPATH envvar, and added that "lib" folder to the end of my LIBRARY_PATH envvar.
I don't know if/how that impacts upon the relevance of the exercise that I undertook.

Maybe some of these issues I've mentioned here have already been addressed upstream somewhere ... I haven't gone looking.

[shawnlaffan]

Thanks for checking Rob.

I imagine there will be other modules that show similar issues with gcc-14 and above so I suspect we need to keep Strawberry Perl at gcc-13 for now.

[sisyphus]

That's probably the simplest approach, given the amount of unmaintained code that's to be found on CPAN.
However, with gcc-14 and above, a better alternative to -Wno-implicit-function-declaration (and friends) is -Wno-error=implicit-function-declaration - which, I believe, allows the warnings to be displayed (just as they would with gcc-13 and earlier), but prevents them from being fatal.
There might even be a single switch that removes the fatality of all of these problematic warnings ... I don't know.
Adding that/those switch/es to SP's CCFLAGS would allow SP to move to gcc-14 and gcc-15.
And it's not a lot of extra work. (Easy for me to say ;-)

For so long as SP honors the -std=c99 switch (currently imposed by GNUmakefile), the problem with C23 is never going to arise when gcc-15 is used to build SP.

I should add that if you choose to stick with gcc-13, then there will be no complaints from me. (I see that gcc-13.3.0 is available from winlibs.)

UPDATE: The last patch I provided to Makefile.PL is corrupted.
$optimize = '-Os-falign-functions .... should, of course, be $optimize = '-Os -falign-functions .....

[alanoflanagan]

Thanks you both for for the work on this. The tests are now passing with the patch. Just to confirm are ye planning on rolling back the gcc version or do ye think the path is a permeant fix.

[shawnlaffan]

Good to hear it works.

We'll be keeping with gcc-13 for the next release.

I'll leave this open for now as I have yet to add a patched version to the system.