Tk-804.036 doesn't have a top-level configure script, but there are quite a few of them at lower levels. If you look back in the log file from the error message, you should be able to see which directory it is configuring in. Find that "cannot create executables" error message in the appropriate configure script and a few lines back (ignoring the scary shell script) you should be able to see the program it is trying to compile.

For example in JPEG/jpeg/configure it tries to compile this:

#line 625 "configure"
#include "confdefs.h"
main(){return(0);}
[download]

If you put the appropriate text in a file and try to compile it from the same directory using the same invocation as you see in the error message, that may either tell you immediately what the problem is or provide more information that might help us to help you.

Thank you very much, kind Monk{hv}. I have progressed, if after long delay on my part (my apologies; I was a bit daunted). The problem was in trying to compile in JPEG/jpeg/configure, lines 625-26, which was as follows:

    625 #include "confdefs.h"
    626 main(){return(0);}
[download]

Running that snippet with same invocation as in the error message, the crux was that it wanted s/main/int main/

I changed the snippet to 'int main', backed up to the main Tk directory, ran perl Makefile.PL there, and progressed to another error, in compiling Xlib_f.c, as follows:

Xlib.t:334:14: error: initialization of ‘KeySym (*)(Display *, unsigne
+d int,  int)’ {aka ‘long unsigned int (*)(Display *, unsigned int,  i
+nt)’} from incompatible pointer type ‘KeySym (*)(Display *, KeyCode, 
+ int)’ {aka ‘long unsigned int (*)(Display *, unsigned char,  int)’} 
+[-Wincompatible-pointer-types]
[download]

If your Monkness could vouchsafe another bit of wisdom about this, I would be most thankful.

You're getting rather beyond my knowledge here, I'm afraid - at this point you may be better off opening an issue in the bug tracker (probably requires a login). (If you do so, I recommend cross-linking with this thread.)

My X11 headers have this in /usr/include/X11/Xlib.h:

_X_DEPRECATED
extern KeySym XKeycodeToKeysym(
    Display*        /* display */,
#if NeedWidePrototypes
    unsigned int    /* keycode */,
#else
    KeyCode     /* keycode */,
#endif
    int         /* index */
);
[download]

It seems that Xlib.t encapsulates a signature assuming the "NeedWidePrototypes" variant, but the way perlTk is including your X11 headers they are providing the alternative variant. I think that you if you invoke make with -DNeedWidePrototypes=1 it may get you further; but it is unclear to me why this is going wrong in the first place.