Tcl/Tk 8.6.10 on macOS Mojave: wish and console are just black windows...

[skuh...@web.de]

Hello,

a few days ago I downloaded Release 8.6.10 and compiled it myself. When starting wish, I only get a black window (the toplevel frame as well as the console).

Even when setting the background via commandline explicitely, it stays black/black, so no use is really possible.

With an older release, downloaded from ActiveState, this does not happen.

I have not tested it on Catalina yet, but will do this weekend.

Anybody had the same problem and found the cause/solution?

Thanks in advance,
Stephan

[Brad Lanam]

This sounds like 8.6.8 on a recent Mojave (10.14.5/6).
Double check which version of tclsh is really being executed.
I have not had any issues with 8.6.10, I compiled on Catalina with XCode
command lines tools 11.2 with the minimum mac version set to 10.11.
I will boot into Mojave and test.

[Brad Lanam]

Compiled on Mojave and no issues.
If you continue to have this issue, you will need to post exactly how
you are building Tcl/Tk.

[ALX]

I also compiled it on Mojave 10.14.6 and had no issues.

[skuh...@web.de]

> This sounds like 8.6.8 on a recent Mojave (10.14.5/6).
> Double check which version of tclsh is really being executed.
> I have not had any issues with 8.6.10, I compiled on Catalina with XCode
> command lines tools 11.2 with the minimum mac version set to 10.11.

Thanks for the hint. That is peculiar... You are right and its even worse, its Tcl 8.6.7.
Here is what I've done:

--------->8---------------
tar zxvf tcl8.6.10-src.tar.gz
tar zxvf tk8.6.10-src.tar.gz
export ver=8.6.10
export CFLAGS="-arch x86_64 -mmacosx-version-min=10.14"
make -C tcl${ver}/macosx --> No errors
file build/tcl/tclsh8.6 --> build/tcl/tclsh8.6: Mach-O 64-bit executable x86_64
build/tcl/tclsh8.6
---------8<---------------

Now in that Tclsh I did:

--------->8---------------
% set tcl_patchLevel
8.6.7
---------8<---------------

WT...? How did that happen? The tclsh seems to use the Tcl-Framework of an older installation, that I have probably installed with homebrew, but why doesn't it use the framework it just compiled?

[Brad Lanam]

Yes, this is one of the problem areas I really dislike about Tcl/Tk.

I actually have my build system edit the init.tcl on Mac OS and fix up
the search paths and I adjust the shared library search paths in the
executables (I also have an additional goal of making the installation
relocatable).

My expectation is like yours, I expect that if I run /somepath/tclsh, then
tclsh should use the libraries and framework in /somepath, not elsewhere.

[skuh...@web.de]

> Yes, this is one of the problem areas I really dislike about Tcl/Tk.

On macOS...

> I actually have my build system edit the init.tcl on Mac OS and fix up
> the search paths and I adjust the shared library search paths in the
> executables (I also have an additional goal of making the installation
> relocatable).

Would be nice, to have that in the default make-process.

> My expectation is like yours, I expect that if I run /somepath/tclsh, then
> tclsh should use the libraries and framework in /somepath, not elsewhere.

Yes, that should be the standard. After the right hints from you guys it just took me only a few minutes to find out about install_name_tool and how to use it to change the hardcoded paths in the binaries. Not too hard to add that to the makefile, I think for both, the compile- and the install-target. Also the auto_path-variable should be adapted automatically then.

I guess I have to write my own post-compile/install-Script also or add that stuff to the makefile for macOS.

Thanks again to all for the hints in the right direction.

[Brad Lanam]

Also be aware that the installation path gets hard-coded into the binary, and
Tcl/Tk will locate .tcl and .tm modules from the original install path (again,
instead of looking in its current location).

I have been bitten by this during my testing process. I haven't looked for
a way to fix this -- I just have to make sure my original install path is
removed so that the testing is correct.

[skuh...@web.de]

Am Samstag, 7. Dezember 2019 00:36:29 UTC+1 schrieb Brad Lanam:
> Also be aware that the installation path gets hard-coded into the binary, and
> Tcl/Tk will locate .tcl and .tm modules from the original install path (again,
> instead of looking in its current location).

How does that work, when make does compiling and installing/copying in two different steps?
And how do you deal with it? - I would have guessed, that this is part of the init.tcl scripts and not directly in the binary.

[Rich]

skuh...@web.de wrote:
> Am Samstag, 7. Dezember 2019 00:36:29 UTC+1 schrieb Brad Lanam:
>> Also be aware that the installation path gets hard-coded into the
>> binary, and Tcl/Tk will locate .tcl and .tm modules from the
>> original install path (again, instead of looking in its current
>> location).
>
> How does that work, when make does compiling and installing/copying
> in two different steps?

Generally it's done during compilation. One of those many CPP defines
that get setup before compilation would contain the eventual install
path, and some line of C somewhere sets up a static string containing
the contents of the CPP define.

> And how do you deal with it? - I would have guessed, that this is
> part of the init.tcl scripts and not directly in the binary.

For compiled in static strings, typically by redefining the CPP define
prior to compiling the .c file that adds in the static string.

As for init.tcl, the C code still needs some way to find init.tcl, so
you'll still end up compiling in at least one path, that being the one
necessary to find init.tcl. Once you've done that, it likely becomes
an either/or whether you defer to init.tcl for the remainder or just
compile in the remainder (as 99% of the C coding and configuration
effort is already done for that first one). One aspect that would sway
the either/or choice towards compiled into the binary would be if
several of the paths were needed by the C init before the Tcl
interpreter is up and ready to interpret init.tcl.

[Brad Lanam]

It would certainly be better to put it in the init.tcl
instead of hard-coding it.

Most of the time, it did not hurt me, as I would be testing with the same
version of code that got compiled, but occasionally it would mess me up.

Finally, I have put the following in my test startup script:

set d [file join $::env(HOME) t localB]
if { [file exists $d] } {
file delete -force $d
exec [info nameofexecutable] [info script] {*}$::argv &
exit
}

[skuh...@web.de]

Am Samstag, 7. Dezember 2019 18:03:39 UTC+1 schrieb Brad Lanam:

> Finally, I have put the following in my test startup script:
>
> set d [file join $::env(HOME) t localB]
> if { [file exists $d] } {
> file delete -force $d
> exec [info nameofexecutable] [info script] {*}$::argv &
> exit
> }

Not really related to my question, I think, but looking at your script:
Is it wanted, that your tests are only performed, if $d existed before and is deleted then? - How about the very first run of the script? That would need at least one manual creation of $d...

[skuh...@web.de]

Am Samstag, 7. Dezember 2019 17:49:12 UTC+1 schrieb Rich:
> > Am Samstag, 7. Dezember 2019 00:36:29 UTC+1 schrieb Brad Lanam:
> >> Also be aware that the installation path gets hard-coded into the
> >> binary, and Tcl/Tk will locate .tcl and .tm modules from the
> >> original install path (again, instead of looking in its current
> >> location).

Thanks, I have to look into the sources then, if there is a good dynamic workaround.

However, what I don't get then is, how precompiled installers work then. E.g. ActiveTcl Installer can set an user defined installation path. How can that work, if all paths are hardcoded at compile-time? The installer doesn't compile anything...

[Brad Lanam]

Oh, $d is the original installation from when I ran the initial build.

The directory is copied to my application tree and installed in an entirely
different location when I run my tests.

[rob...@crosstab.com]

Last year I downloaded from git 8.6.9 including a bug fix for a double click bug. I don't see right now
how to identify the exact version or fix. I built it on Mojave and It works fine on several macs with Mojave,
but 1 user says that windows in our application often turn black (entirely or a portion) until the mouse is moved. It is a brand new mac. Do you know if this would be fixed in 8.6.10 as well.

Thank you,

Robert Karen