Any suggestions, and thanks in advance?
FWIW, we're seeing the same sort of thing on 64-bit Windows perls built using gcc-13.1.0.
There's some other Windows-specific issues discussed there as well, but the blocker is a crash in t/basic.t and t/crash.t.
Tk-804.036 builds, tests and installs fine if perl was built with gcc-8.3.0 - though it's untested whether you have to go that far back.
We also found that Tk-804.036 is fine on 32-bit perls built using gcc-13.1.0 (in 32-bit mode).
I don't know if any of you Macs guys are able to test out either of those different perl scenarios on your systems. If you are, then I'd be interested to hear what you find.
I've been assuming that all of the issues we're seeing on Windows were specific to Windows .... but maybe some of them are due to a more general issue with 64-bit gcc-13.1.0 ??
How does Tk-804.036 fair on 64-bit Linux perls built with gcc-13.1.0 ?
Cheers,
Rob | [reply] |
Rob,
Installing real gcc (not clang) on macOS is fraught with compatibility issues, so I installed a fresh Ubuntu 22.0.4 in VirtualBox. Fetched gcc (11.3.0) with apt and attempted to build Tk with cpanm into perl 5.34.0. This required libx11-dev which built without errors. However, alas, building Tk with sudo failed with the following linker errors in root's build log, to wit:
ar rcs libpng.a png.o pngerror.o pngget.o pngmem.o pngpread.o pngread.
+o pngrio.o pngrtran.o pngrutil.o pngset.o pngtrans.o pngwio.o pngwrit
+e.o pngwtran.o pngwutil.o
: libpng.a
make[2]: Leaving directory '/root/.cpanm/work/1688142289.10679/Tk-804.
+036/PNG/libpng'
make[2]: Entering directory '/root/.cpanm/work/1688142289.10679/Tk-804
+.036/PNG/libpng'
x86_64-linux-gnu-gcc -fPIC -c -Wall -O2 -I../zlib pngtest.c
x86_64-linux-gnu-gcc -s -L../zlib -o pngtest pngtest.o libpng.a -lz -l
+m
/usr/bin/ld: libpng.a(pngread.o): in function `png_read_row':
pngread.c:(.text+0x10fd): undefined reference to `png_combine_row'
/usr/bin/ld: pngread.c:(.text+0x1121): undefined reference to `png_com
+bine_row'
/usr/bin/ld: pngread.c:(.text+0x11d6): undefined reference to `png_com
+bine_row'
/usr/bin/ld: pngread.c:(.text+0x11f0): undefined reference to `png_com
+bine_row'
/usr/bin/ld: pngread.c:(.text+0x122a): undefined reference to `png_rea
+d_filter_row'
/usr/bin/ld: pngread.c:(.text+0x1292): undefined reference to `png_do_
+read_interlace'
/usr/bin/ld: pngread.c:(.text+0x12e0): undefined reference to `png_com
+bine_row'
/usr/bin/ld: pngread.c:(.text+0x1337): undefined reference to `png_com
+bine_row'
/usr/bin/ld: pngread.c:(.text+0x136a): undefined reference to `png_com
+bine_row'
/usr/bin/ld: pngread.c:(.text+0x13a0): undefined reference to `png_com
+bine_row'
/usr/bin/ld: pngread.c:(.text+0x13de): undefined reference to `png_com
+bine_row'
/usr/bin/ld: libpng.a(pngread.o):pngread.c:(.text+0x1416): more undefi
+ned references to `png_combine_row' follow
/usr/bin/ld: libpng.a(png.o): in function `png_init_mmx_flags':
png.c:(.text+0xb33): undefined reference to `png_mmx_support'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:58: pngtest] Error 1
make[2]: Leaving directory '/root/.cpanm/work/1688142289.10679/Tk-804.
+036/PNG/libpng'
make[1]: *** [Makefile:519: subdirs] Error 2
make[1]: Leaving directory '/root/.cpanm/work/1688142289.10679/Tk-804.
+036/PNG'
make: *** [Makefile:769: subdirs] Error 2
-> FAIL Installing Tk failed.
I can't build Tk with either clang 9.2 or 10.1 on High Sierra, but I was hoping to do Tk dev on Ubuntu, but that too seems now to be closed off. Since Python (3.11.4) works perfectly with tkinter on my existing mac, that seems the best option. I know those two versions of clang are problematic, especially with macro expansion. I went round and round with the PDL pumpking re segmentation fault building pdlcore.c in 2.083. The C standard talks about macro length limitations, but fails to specify a value, leaving it up to compiler builder discretion (your mileage will vary). I stepped through pdlcore.c with #if 0...#endif until I found the macro,
#define PDL_KLUDGE_COPY_X(X, datatype_out, ctype_out, ppsym_out, ...)
+\
that was causing the fault. I shortened two variables, cursor to c and target to t in a loop and like magic, pdlcore.c compiled. I reported this to the developers but the answer (totally bogus) was to strip out all comments and white space to shorten that macro. I argued till I was blue in the face that the C preprocessor does that, but the pumpking went ahead and released PDL 2.084 with pdlcore.c stripped of white space. As expected, its pdlcore.c segmentation faulted with both of my clangs just as the previous version had. I copied all the C headers and both versions of pdlcore.c to a private directory and preprocessed them with gcc -E, and both were identical. I reported this too to the PDL developers list but as yet have heard zero response, which means PDL is compromised in my version of macOS. Sure, my kludge fix within a kludge works for now, but if I ever try to upgrade PDL I will face the same issue. The good news, and it is very good news mixed with some bad is that PDL 2.084 builds without errors in Ubuntu. The bad is, of course, Tk builds on neither. So, I have PDL on Ubuntu, Tk nowhere, but Python with tkinter everywhere. Needless to say, I want to get on with my work rather than spend so much of my time on Perl admin.
| [reply]
[d/l]
[select] |
G'day Rob,
I don't know if any of the following will help, but here's some Perl, Tk and gcc version information for comparison.
I've provided info for Perl 5.30 (which the OP had problems with) and Perl 5.36 (which you've had problems with)
— note that I have different subversions.
I install Tk with all of my Perl versions.
I usually get an error or two from `make test`, but nothing catastrophic;
although, I seem to recall that I couldn't build Tk years ago (maybe Perl 5.26).
I install with the cpan utility (force install Tk when tests fail).
I run several of the widget demos, as additional tests, when `make test` fails.
I'm running Cygwin version 3.4.7 on Win10.
I update both of these weekly; last done about seven hours ago.
Currently cmd.exe starts by showing:
Microsoft Windows [Version 10.0.19045.3155]
(c) Microsoft Corporation. All rights reserved.
Cygwin's latest version of gcc:
$ gcc --version
gcc (GCC) 11.4.0
I get Perl module version and location info with perlmodver:
Perl v5.30
$ perl -v | head -2 | tail -1
This is perl 5, version 30, subversion 0 (v5.30.0) built for cygwin-th
+read-multi
$ perl -V
Summary of my perl5 (revision 5 version 30 subversion 0) configuration
+:
Platform:
osname=cygwin
osvers=3.0.7(0.33853)
archname=cygwin-thread-multi
uname='cygwin_nt-10.0 titan 3.0.7(0.33853) 2019-04-30 18:08 x86_64
+ cygwin '
...
gccversion='7.4.0'
...
$ perlmodver Tk
Tk 804.034
in /home/ken/perl5/perlbrew/perls/perl-5.30.0/lib/site_perl/5.30.0/c
+ygwin-thread-multi/Tk.pm
----------------------------------------------------------------------
+--
Full perl -V output:
Perl v5.36
$ perl -v | head -2 | tail -1
This is perl 5, version 36, subversion 0 (v5.36.0) built for cygwin-th
+read-multi
$ perl -V
Summary of my perl5 (revision 5 version 36 subversion 0) configuration
+:
Platform:
osname=cygwin
osvers=3.2.0(0.34053)
archname=cygwin-thread-multi
uname='cygwin_nt-10.0 titan 3.2.0(0.34053) 2021-03-29 08:42 x86_64
+ cygwin '
...
gccversion='10.2.0'
...
$ perlmodver Tk
Tk 804.036
in /home/ken/perl5/perlbrew/perls/perl-5.36.0/lib/site_perl/5.36.0/c
+ygwin-thread-multi/Tk.pm
----------------------------------------------------------------------
+--
Full perl -V output:
| [reply]
[d/l]
[select] |
I'm running Linux Mint, based on Ubuntu 22.04, and the Synaptic package manager doesn't offer anything later than gcc-12.1.0 (which does build perl and perl Tk successfully).
| [reply] |
My naive suggestion would be to try with gcc if possible. | [reply] |
I used cpanm to install Perl Tk 804.036 on my 2013 Mac running MacOS 10.15.7 and perl 5.30.3, and got the same result. I'm going to try gnosti's suggestion and use gcc. Note that /usr/bin/gcc is really clang. I used homebrew to install a true gcc-13.1.0 (the entire build took 1.5 hrs!) and will try tomorrow to figure out how to build Tk with gcc.
Does anyone know if such a build would be compatible with my clang-built perl, or would I also need to recompile perl with gcc?
| [reply] |
In the same naive spirit, I would offer that using the same compiler for building perl and its extensions seems more likely to succeed. If I could reason about symbols and libraries and memory addresses, I would be able to explain why. I know in some ways it isn't especially complicated, but you do need to learn how to reason about it, which is possible only through actually debugging experience, at least for myself.
Tk isn't especially easy to compile. Since so many perl modules are available through Debian, it's a suitable development environment in that it gets you a compiled Tk for free. When I compile Tk for myself, under whichever perl version, I always have to force it to install as there is always a failing test. I just believe and pray I won't touch that code because I never bothered to try and figure it out. Up to now I've been a rather pedestrian user. No nuclear reactors depend on my code!
I'm aware there's another Tk interface for perl, Tkx. I've never touched it, but understand it is closer to Tcl/Tk than the more perlish Tk. Perhaps Tkx will compile and work for your app under clang.
| [reply] |
No joy after compiling both perl-5.30.3 and Tk 804.036 with gcc 13.1.0. Tk install appears to fail the same tests, although now there's no mention of a SEGV, and perl gets stuck in a CPU loop.
"/Users/chap/perl5/perlbrew/perls/perl-5.30.3/bin/perl" "-I../t" "-MTk
+Test" "-e" "checked_test_harness('../xt', 0, '../blib/lib', '../blib/
+arch')" t/*.t
t/basic.t .. Failed 4/5 subtests
t/crash.t ..
FWIW, I was able to install Perl Tk just fine on M1 MacBook Air running MacOS 13.4.1 (Ventura), in both perl-5.36.1 and perl-5.38.0-RC2. | [reply]
[d/l] |
| [reply]
[d/l] |