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,
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,
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,
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?
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,
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.
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)
| ^
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,
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.
Thanks @hakonhagland.
I can confirm that the code presented by @chrstphrchvz in chrstphrchvz/perl-tk@0cc1fd7 fixes the "ControlMask" issue nicely.
Cheers,
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
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'.
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.
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,
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)
