Updating tk +quartz failed on Snow Leopard

[Ryan Schmidt]

> On Aug 23, 2016, at 8:40 PM, Richard L. Hamilton <rlhamil at smart.net> wrote:
> 
> 
>> On Aug 23, 2016, at 21:06, Ryan Schmidt <ryandesign at macports.org> wrote:
>> 
>> 
>>> On Aug 23, 2016, at 8:03 PM, Richard L. Hamilton <rlhamil at smart.net> wrote:
>>> 
>>> 
>>>> On Aug 23, 2016, at 10:38, Ryan Schmidt <ryandesign at macports.org> wrote:
>>>> 
>>>> On Aug 23, 2016, at 07:02, Mojca Miklavec <mojca at macports.org> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>> On 23 August 2016 at 02:00, Ken Cunningham wrote:
>>>>>>> On 2016-08-22, at 3:48 PM, Richard L. Hamilton wrote:
>>>>>>> Updating tk failed on Snow Leopard, trying to update to the current tk at 8.6.6 (probably +quartz+universal, given that's what the current @8.6.5_0 is)
>>>>>> Hi Richard,
>>>>>> 
>>>>>> I have tk 8.6.6 running on snow leopard, but with +x11 (and not universal, but x86_64)
>>>>>> 
>>>>>> $ port -v installed tk
>>>>>> The following ports are currently installed:
>>>>>> tk @8.6.6_0+x11 (active) platform='darwin 10' archs='x86_64'
>>>>>> 
>>>>>> for what that's worth. I installed it with clang-3.7, and my first thought is that your compiler might be too old. You might try installing clang-3.7 (and ld64/cctools/llvm-3.7 that go along with it) and see where that takes you....
>>>>> 
>>>>> The "official" binaries are indeed available for 10.6 and they were
>>>>> compiled with the default compiler:
>>>>> http://packages.macports.org/tk/
>>>>> 
>>>>> I can confirm that tk +quartz compiles fine for me on 10.7, but not on
>>>>> 10.6 (not even with clang 3.4, I didn't test with 3.7).
>>>>> 
>>>>> I don't find a ticket in the tracker, so feel free to open one. The
>>>>> closest one I found was
>>>>> https://trac.macports.org/ticket/22994
>>>>> but that one is ancient and most likely unrelated.
>>>> 
>>>> The official binaries are built on a system with Xcode 3.2.6 and therefore use gcc-4.2, which evidently works. 
>>>> 
>>>> The user is using Xcode 4.2, and the log shows llvm-gcc-4.2 is being used, which evidently doesn't work. We should blacklist that compiler in the port. 
>>>> 
>>> 
>>> While the problems may not be identical depending on the compiler, that alone isn't the answer.  I installed Xcode 3.2.6 (and made sure that xcode-select -print-path showed that version), and it still failed.  I cleaned and added -universal...and it still failed.  I did that again adding -quartz...and it found the pre-built binaries.
>>> 
>>> I see the pre-built hasn't used +quartz for a number of versions, although I have evidently gotten it to work before:
>>> sh-3.2# port installed tk
>>> The following ports are currently installed:
>>> tk @8.6.5_0+quartz+universal
>>> tk @8.6.6_0+x11 (active)
>>> 
>>> So the problem may be specific to trying to build tk at 8.6.6_0+quartz.
>> 
>> Yes, I agree, sorry, Mojca responded to me privately that the problem isn't the compiler, it's the +quartz variant, and I confirmed that on my system too. This problem needs to be reported to the developers of tk so it can be fixed.
>> 
>> +quartz used to be the default variant but it was changed last year:
>> 
>> https://trac.macports.org/changeset/141308
> 
> The problem is also specific to some OS versions, Snow Leopard for sure.  I have the current version on El Capitan with +quartz, no problem.

No doubt they made a change and tested it on a recent version of macOS before releasing it.


> Is there an email or URL for reporting that?  And someone other than me with Snow Leopard around for testing, since I certainly don't know how to turn their tarball into a locally installable port bundle.

Looks like these are the bug reporting instructions:

http://wiki.tcl.tk/1020


I think the problem is the addition of this code in tk 8.6.6, though I don't understand why it's a problem:


@@ -885,7 +890,19 @@
     int	        bitmap_pad = 0;
     int	        bytes_per_row = 4*width;
     int                size;
-    TkMacOSXDbgMsg("XGetImage");
+    MacDrawable *macDraw = (MacDrawable *) d;
+    NSWindow *win = TkMacOSXDrawableWindow(d);
+    /* This code assumes that backing scale factors are integers.  Currently
+     * Retina displays use a scale factor of 2.0 and normal displays use 1.0.
+     * We do not support any other values here.
+     */
+    int scalefactor = 1;
+    if (win && [win respondsToSelector:@selector(backingScaleFactor)]) { 
+	scalefactor = ([win backingScaleFactor] == 2.0) ? 2 : 1;
+    }
+    int scaled_height = height * scalefactor;
+    int scaled_width = width * scalefactor;
+
     if (format == ZPixmap) {
 	if (width == 0 || height == 0) {
 	    /* This happens all the time.


This is the commit that added that code:

http://core.tcl.tk/tk/info/c6301aba29addea1


The line the error complains about is the one that calls [win backingScaleFactor]. The complaint was:


error: invalid operands to binary == (have ‘id’ and ‘double’)


So [win backingScaleFactor] must have returned an id, and 2.0 is a double, and those types can't be compared.

This is weird because the backingScaleFactor method is supposed to return a double, not an id, and is part of the Retina display API introduced in Mac OS X 10.7. It is not in 10.6. The window should not be responding to the backingScaleFactor selector on 10.6, so that if statement should never have returned true and that code should never have been run.