Tk build fails (Perl 5.36 sp536 20230420)

[HaraldJoerg]

I'm happy to see this progress! Great work!

I have tried to run my Perl applications under this version. One module which fails to install is Tk. The build log has 3200 lines, I'll provide the whole of it if there's a chance that it contains useful informations.

The tests that fail are in the PNG subdirectory:

Test Summary Report
-------------------
t/basic.t (Wstat: 1280 (exited 5) Tests: 2 Failed: 0)
  Non-zero exit status: 5
  Parse errors: Bad plan.  You planned 5 tests but ran 2.
t/crash.t (Wstat: 1280 (exited 5) Tests: 0 Failed: 0)
  Non-zero exit status: 5
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=2, Tests=2,  1 wallclock secs ( 0.00 usr +  0.00 sys =  0.00 CPU)
Result: FAIL
Failed 2/2 test programs. 0/2 subtests failed.
gmake[1]: *** [makefile:863: test_dynamic] Error 5
gmake[1]: Leaving directory 'C:/Users/Haral/perl5/data/.cpanm/work/1682426920.15880/Tk-804.036/PNG'

After installing anyway, programs using Tk crash like this:

Signal SEGV at C:/Users/Haral/perl5/perl/site/lib/Tk/Widget.pm line 190.
        Tk::Widget::new("Tk::Menu", MainWindow=HASH(0x24e4b84c1b8)) called at C:/Users/Haral/perl5/perl/site/lib/Tk/Widget.pm line 256
        Tk::Widget::__ANON__[C:/Users/Haral/perl5/perl/site/lib/Tk/Widget.pm:256](MainWindow=HASH(0x24e4b84c1b8)) called at D:/test/flowers/bin/../lib/O3D/UI.pm line 71
        O3D::UI::init_ui(O3D::UI=ARRAY(0x24e47276550)) called at D:/test/flowers/bin/../lib/O3D/UI.pm line 65
        O3D::UI::__ANON__[D:/test/flowers/bin/../lib/O3D/UI.pm:68](O3D::UI=ARRAY(0x24e47276550), HASH(0x24e4b836588)) called at D:/test/flowers/bin/../lib/O3D/UI.pm line 44
        O3D::UI::run("O3D::UI") called at bin\modeler.pl line 8

The calling line (O3D/UI.pm line 71) is as simple as my $menubar = $top->Menu();

For me personally, that issue is not urgent: I am currently rewriting that GUI to Prima, and Prima works fine under 5.36.

[shawnlaffan]

Thanks for the report. I can reproduce the errors.

FWIW I get the log below when running perl Makefile.PL.

The struct pmop errors look suspicious.

I'm also not sure what is causing the Warning (mostly harmless): No library found for C:/user/strawberry/sp536_20230420b/c/lib/gcc/x86_64-w64-mingw32/8.3.0 warnings. They are probably from a re-used Strawberry perl 5.32 file but they should be harmless.

@eserte - fyi

C:\user\strawberry\sp536_20230420b\perl\bin\perl.exe is installed in C:\user\strawberry\sp536_20230420b\perl\lib okay
PPM for perl5.036000
Test Compiling config/perlrx.c
Test Compiling config/pmop.c
config/pmop.c: In function 'main':
config/pmop.c:7:8: error: 'struct pmop' has no member named 'op_pmdynflags'; did you mean 'op_pmflags'?
    7 |     op.op_pmdynflags = 0;
      |        ^~~~~~~~~~~~~
      |        op_pmflags
config/pmop.c:8:8: error: 'struct pmop' has no member named 'op_pmpermflags'; did you mean 'op_pmflags'?
    8 |     op.op_pmpermflags = 0;
      |        ^~~~~~~~~~~~~~
      |        op_pmflags
Test Compiling config/pregcomp2.c
In file included from C:\user\strawberry\sp536_20230420b\perl\lib/CORE/perl.h:5837,
                 from config/pregcomp2.c:2:
config/pregcomp2.c: In function 'main':
C:\user\strawberry\sp536_20230420b\perl\lib/CORE/embed.h:464:24: warning: initialization of 'regexp *' from incompatible pointer type 'REGEXP *' {aka 'struct p5rx *'} [-Wincompatible-pointer-types]
  464 | #define pregcomp(a,b)  Perl_pregcomp(aTHX_ a,b)
      |                        ^~~~~~~~~~~~~
C:\user\strawberry\sp536_20230420b\perl\lib/CORE/embed.h:464:24: note: in definition of macro 'pregcomp'
  464 | #define pregcomp(a,b)  Perl_pregcomp(aTHX_ a,b)
      |                        ^~~~~~~~~~~~~
Test Compiling config/regexp511.c
Test Compiling config/signedchar.c
config/signedchar.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
    1 | main()
      | ^~~~
Test Compiling config/Ksprintf.c
Test Compiling config/svtrv.c
config/svtrv.c: In function 'main':
config/svtrv.c:9:5: error: duplicate case value
    9 |     case SVt_IV:
      |     ^~~~
config/svtrv.c:8:5: note: previously used here
    8 |     case SVt_RV:
      |     ^~~~
Test Compiling config/copstashset.c
Skip InputO on MSWin32
Skip Mwm on MSWin32
Skip WinPhoto on MSWin32
Warning (mostly harmless): No library found for C:/user/strawberry/sp536_20230420b/c/lib/gcc/x86_64-w64-mingw32/8.3.0
Warning (mostly harmless): No library found for C:/user/strawberry/sp536_20230420b/c/lib/gcc/x86_64-w64-mingw32/8.3.0
Generating Dependencies for MSWin32, win_arch=MSWin32
Test Compiling config/Hstrtoul.c
config/Hstrtoul.c: In function 'main':
config/Hstrtoul.c:6:26: warning: implicit declaration of function 'strcmp' [-Wimplicit-function-declaration]
    6 |  if (v != 0xDEADFACEL || strcmp(e,"gibberish"))
      |                          ^~~~~~
Test Compiling config/Hstrdup.c
config/Hstrdup.c: In function 'main':
config/Hstrdup.c:9:3: warning: implicit declaration of function 'exit' [-Wimplicit-function-declaration]
    9 |   exit(1);
      |   ^~~~
config/Hstrdup.c:9:3: warning: incompatible implicit declaration of built-in function 'exit'
config/Hstrdup.c:2:1: note: include '<stdlib.h>' or provide a declaration of 'exit'
    1 | #include <string.h>
  +++ |+#include <stdlib.h>
    2 |
Test Compiling config/Hstrcasecmp.c
<snip>

[sisyphus]

I'm using strawbewrry-perl-5.36.1.1 dev release.
Ignoring the (above mentioned) config complaints in the Makefile.PL stage, when I run gmake, after a few seconds I get the following garbage:

gcc -c <snip> imgBMP.c
In file included from ../pTk/mTk/xlib/X11/Xlib.h:31,
                 from tkWinPort.h:19,
                 from tkPort.h:32,
                 from tk.h:87,
                 from imgBMP.c:11:
../pTk/mTk/xlib/X11/X.h:182:26: error: expected identifier or '(' before numeric constant
  182 | #define ControlMask     (1<<2)
      |                          ^
gmake[1]: *** [makefile:891: imgBMP.o] Error 1
gmake[1]: Leaving directory 'C:/Users/Owner/.cpan/build/Tk-804.036-0/pTk'
gmake: *** [makefile:1634: pTk/libpTk.a] Error 2

There's nothing syntactically wrong with line 182, and I can't reproduce the error in a C program, or an Inline::C script .... or in any other environment for that matter.
I've tried undeffing ControlMask ahead of the #define., and a couple of other silly things ... none of which made any difference.

Apparently "ControlMask" is something special, and tonight I'll replace it with ControlMask_pTK in the various files in the Tk distro that include the symbol (all of which are inside the pTK folder).

Any insights into why this problem arises, and how better to handle it ?

Cheers,
Rob

[shawnlaffan]

I get the same. I have no insights into the whys and wherefores, though.

[sisyphus]

Renaming "ControlMask" to something else (I chose "ControlMask_pTK") worked in that it enabled the gmake step to successfully run to competion.
But, as @HaraldJoerg reported, PNG/t/basic.t and PNG/t/crash.t both abort prematurely and, under make test, the test suite then abruptly ceases.
Running gmake -i test ensures that the test suite continues on.
If there was a test script that ran to completion and passed then I missed seeing it.

After running gmake realclean I tried a rebuild with perl Makefile.PL OPTIMIZE=-Os in case that would help.
It didn't.

I suspect that the patch to win32/vmem.h is only a part of the solution to the alignment issue it was supposed to solve.

Cheers,
Rob

[shawnlaffan]

Does it build with Perl 5.37.x? If so then the same search strategy used for PDL might be of use.

[sisyphus]

A good idea and worth a try, but no luck :-(
The 5.37.11 build of Tk-804.036 fails the tests in exactly the same way.

Cheers,
Rob

[shawnlaffan]

A good idea and worth a try, but no luck :-(
The 5.37.11 build of Tk-804.036 fails the tests in exactly the same way.

Ah well.

Does it also fail for 5.37.x built with gcc-83 from SP5.32? I think you have builds using that, or at least have done in the past?

[sisyphus]

Does it also fail for 5.37.x built with gcc-83 from SP5.32?

Tk 804.036 builds, tests and installs just fine for that perl.
(BTW, it still produces the same errors during the configuration determinations conducted during the Makefile.PL step, but there are no problems with "ControlMasK' or any other bullshit.)

This has the hallmarks of being an alignment issue.
I think that something in the creation of the "MainWindow" object needs re-aligning for x64 gcc-13 builds of Tk.
But I don't really know how to identify that "something", beyond doing trial-and-error experiments - even if I can locate the file(s) that are responsible for determining the makeup of the "MainWindow" object.
(I call it a "MainWindow" object because that's what ref() reports.)

I might see if I can knuckle down and fix the relevant Tk code .... or I might not.
TBC, I'm thinking that this issue will be fixed by an alteration to the Tk code, rather than a patch to perl source - but there's no guarantee that such thinking is the correct approach.
For many years (going back to gcc-8 and probably earlier) I've had to specify alignment for the __float128 type on x64 mingw-w64 builds of my Math::Float128 builds.
Now that the win32/vmem.h patch is in place, it seems that Math::Float128 no longer needs that treatment. (Needs a closer look before I draw definite conclusions.)

It's a pity we don't have 32-bit SP-5.37.11 built using gcc-13.
To date, this alignment issue has only afflicted the x64 mingw-w64 builds, so I would guess that Tk-804.036 would build fine on a 32-bit SP-5.37.11 built using gcc-13.

Cheers,
Rob

[shawnlaffan]

Thanks Rob.

There is a 32-bit release of Winlibs gcc-13 if you're tempted. It gets messy if Tk also needs DLLs for libpng etc, although these could perhaps be recycled from a 32-bit SP5.32 if the mis-alignment is only in the Tk code.

Or it can just be reported upstream.

[sisyphus]

I already had a 32-bit winlibs gcc-13 build of of perl-5.37.11.

When I build Tk-804.036 on that perl (using 32-bit SP5.32.1 libs), the build goes well with all tests passing.
However, I did first have to work around that "ControlMask" problem in the way I described earlier.

Apart from the "ControlMask" issue this is again consistent with my expectations of the x64 alignment issue.

The "ControlMask" problem arises when the problematic #define ControlMask (1<<2)precedes the inclusion of processthreadsapi.h:

D:\C>type try.c
#define ControlMask     (1<<2)
#include <processthreadsapi.h>

int main (void) {
  return 0;
}

D:\C>gcc -c try.c -fdiagnostics-color=never
try.c:1:26: error: expected identifier or '(' before numeric constant
    1 | #define ControlMask     (1<<2)
      |                          ^

D:\C> 

I will look at the possibility of defining ControlMask after processthreadsapi.h has been included, as that seems to be
acceptable to C.
This problem didn't arise with gcc-8.3 because its processthreadsapi.h doesn't contain the "ControlMask" symbol, though it's there in gcc-11.3 and later.

BTW, if anyone wonders why my copy'n'pastes sometimes contain "-fdiagnostics-color=never" it's because I generally have a number of cmd.exe shells on the go, each with a different color scheme - a color scheme that, without that flag, gets permanently clobbered (to white on black) if a warning or error occurs.

Cheers,
Rob

[hakonhagland]

See also: eserte/perl-tk#87

[shawnlaffan]

Thanks @hakonhagland and @sisyphus

The memory alignment issues should probably be raised on the Tk issue tracker so it gets more eyes familiar with that code.

It's not a blocker for Strawberry Perl but one does wonder what other modules have such alignment issues. Still, such modules will need to be fixed at some point so I'm not considering them a blocker for Strawberry Perl 5.36.

[sisyphus]

See also: eserte/perl-tk#87

Thanks @hakonhagland.
I can confirm that the code presented by @chrstphrchvz in chrstphrchvz/perl-tk@0cc1fd7 fixes the "ControlMask" issue nicely.

Cheers,
Rob

[shawnlaffan]

Perhaps a red herring, but there are issues with ioctl when using a pointer to an unsigned integer.
#103 (comment)

Tk has a few uses of ioctl in its code base, albeit mostly in the Unix code. Edit - and none in the perl code.
https://github.com/search?q=repo%3Aeserte%2Fperl-tk%20ioctl&type=code

[marioroy]

Perhaps a red herring, but there are issues with ioctl when using a pointer to an unsigned integer.

I added a comment to #103, verifying which of the two changes resolved the issue or both in the case of MCE. It turns out that passing a pointer to ioctl was the sole reason for MCE failing running Strawberry Perl 5.36.1. Note: The use of ioctl in MCE is only on the Windows platform, specifically $^O eq 'MSWin32'.

[shawnlaffan]

See also eserte/perl-tk#92 (comment)

I think this issue can be closed now. As with #122, the issue is with Tk, there is a fix available, and we don't distribute Tk with Strawberry (although maybe one day).

I'll do so in a few days, or perhaps later when I do another sweep across the issues.

[sisyphus]

Are there any yet-to-be-resolved issues regarding other modules that build fine on x64 5.32.1, but not on x64 5.38.0 ?

I hadn't considered the possibility that such anomalies might be explained by the fact that the x64 5.32.1 environment avoids memory addresses that overflow 32-bits, in places where the x64 5.38.0 environment embraces them.
At least, that's (now) my take on what was happening wrt Tk-804.036.

Are there any other modules that might be suffering from the same ailment ?
( I now think it might also have been the very issue afflicting T1 ... though I gather that omitting T1 is probably the pertinent thing to do, anyway. )

Cheers,
Rob

[shawnlaffan]

That was the issue with t1lib. Patching I would have involved too many changes for it to be worthwhile given its upstream status.

I would speculate that a similar issue affects OpenGL. See #102 and Perl-GPU/pogl#3

There is also PDL::Graphics::PLplot in #26 but that seems not to be Strawberry specific #26 (comment)

[shawnlaffan]

Closing issue.

If there are build problems with other modules then they can be reported as new issues.