tcl-mac — Q&A for Tcl on the Macintosh platform

[MACTCL] Still Cannot Build TclTk on MacOS10.15

[Kevan H. <ha...@br...>]

Greetings from Boston,

I removed all traces of GCC and developer tools from my MacOS10.15.7 machine, including Home Brew versions. I re-installed Command Line Tools. I try to build Tcl 8.6.11 with:

export CFLAGS="-arch x86_64"
make -C tcl/macosx

It fails during the link with undefined symbols. Link error is below. Uwe Kirschner and I were asking for help with this same problem a couple of months ago. If I move to a machine running MacOS 10.12.6, I can compile any version of TclTk I like. But I can compile none of them on my 10.15.7 machine. Is anyone else able to compile TclTk on MacOS 10.15?

Best, Kevan

Undefined symbols for architecture x86_64:
   "_TclOOInitializeStubs", referenced from:
       _Initialize in itclBase.o
   "_Tcl_InitStubs", referenced from:
       _Initialize in itclBase.o
   "_tclIntStubsPtr", referenced from:
       _Itcl_NRRunCallbacks in itcl2TclOO.o
       _Tcl_InvokeClassProcedureMethod in itcl2TclOO.o
       _ItclGetInstanceVar in itclObject.o
       _ItclSetInstanceVar in itclObject.o
       __Tcl_GetOriginalCommand in itclTclIntStubsFcn.o
       __Tcl_CreateProc in itclTclIntStubsFcn.o
       __Tcl_GetObjInterpProc in itclTclIntStubsFcn.o
       ...
   "_tclOOIntStubsPtr", referenced from:
       _Itcl_PublicObjectCmd in itcl2TclOO.o
       _Itcl_NewProcClassMethod in itcl2TclOO.o
       _Itcl_NewProcMethod in itcl2TclOO.o
       _Itcl_NewForwardClassMethod in itcl2TclOO.o
   "_tclOOStubsPtr", referenced from:
       _RootCallProc in itclBase.o
       _Initialize in itclBase.o
       _ItclExtendedConfigure in itclBuiltin.o
       _ItclExtendedCget in itclBuiltin.o
       _ItclUnknownGuts in itclBuiltin.o
       _Itcl_BiInstallComponentCmd in itclBuiltin.o
       _Itcl_BiMyMethodCmd in itclBuiltin.o
       ...
   "_tclStubsPtr", referenced from:
       _Tcl_InvokeClassProcedureMethod in itcl2TclOO.o
       _Itcl_InvokeEnsembleMethod in itcl2TclOO.o
       _EnsembleErrorProc in itcl2TclOO.o
       _FreeProcedureMethod in itcl2TclOO.o
       _Itcl_PublicObjectCmd in itcl2TclOO.o
       _Itcl_SelfCmd in itcl2TclOO.o
       _Itcl_TclOOObjectName in itcl2TclOO.o
       ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [libitcl4.2.1.dylib] Error 1
make[3]: *** [packages] Error 2
make[2]: *** [build-tcl] Error 2
make[1]: *** [tcl] Error 2
make: *** [develop] Error 2

  
-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] [TCLCORE] Commit 9fda84d2

[Christopher C. <chr...@gm...>]

Sent: Monday, May 03, 2021 at 5:14 PM
From: "Marc Culler" <mar...@gm...>

> Hi Jan,
 
> I disagree with your change in 9fda84d2, where you remove the first two parameters of TkpPutRGBAImage.  The reason that you give is that those parameters are not used on macOS.  But that is a bad reason, since those parameters would be used on other platforms, notably X11.
 
> The whole point was to have a function with the exact same signature as TkPutImage.  It is meant to replace TkPutImage for platforms which are able to use native code (and hence the graphics card) to do Porter-Duff source-over blending.  tkImgPhInstance can do that blending without using the graphics card if necessary, but now it will call TkpPutRGBAImage on platforms that provide it.  I had in mind that the function should be exported as a stub, and that is another reason why the signature should be the same for all platforms.
 

While it makes sense to me for TkpPutRGBAImage() to be a replacement for TkPutImage(), I do think it is okay to remove the *colors/ncolors parameters for TkpPutRGBAImage(); I don’t think they would be used on any platform. For TkPutImage(), they are only used on Windows (and only for one call in TkImgDitherInstance()), and actually appear to be unused on X11 (see tkUnixPort.h). I also think it would be reasonable for TkpPutRGBAImage() to only accept non-palette 32-bpp ZPixmaps, and not have to handle anything that TkPutImage() can do.

Christopher A. Chavez

Re: [MACTCL] Mach-O ID of Tcl 8.7a3 Library

[Kevan H. <ha...@br...>]

Dear Marc,

> As I said, the LC_ID_DYLIB path is not used for loading any shared 
> libraries...

I understand, and thank you for explaining.

> While the loader ignores LC_ID_DYLIB, the linker uses it.

Indeed, so changing the LC_ID_DYLIB from one version of Tcl to the next creates problems for people linking to the library. And when the Tk library does not follow the same change, this creates further confusion. But I see that these problems are easily overcome.

> What I think is the correct approach is to have the LC_ID_DYLIB path
> be @rpath/Tcl.

I agree, and with your macher utility, I am able to do this. Thank you.

I gave 8.7a3 a thorough TCPIP and image-display work-out today and it was fast and stable, so I am delighted.

Best Wishes, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] Mach-O ID of Tcl 8.7a3 Library

[Marc C. <mar...@gm...>]

As I said, the LC_ID_DYLIB path is not used for loading any shared
libraries.  So it is completely irrelevant to the process by which " the
embedded Wish is supposed to call its own frameworks".  While the loader
ignores LC_ID_DYLIB, the linker uses it.  When you link against the Tcl
library the linker writes the LC_ID_DYLIB that it finds for Tcl into the
resulting Mach-O file as its LC_LOAD_DYLIB path.  So it is true that if you
linked your X.dylib against
/Library/Frameworks/Tcl.Framework/Versions/8.7/Tcl and if the LC_ID_DYLIB
of that Tcl was set
to @loader_path/../Frameworks/Tcl.framework/Versions/8.7/Tcl then your
X.dylib would be embeddable in an application that contained a Tcl
framework.  But that is not the only possible situation where one might
want to link against  /Library/Frameworks/Tcl.Framework/Versions/8.7/Tcl.
It is also true that if your embedded Tcl library had its LC_ID_DYLIB path
set to @executable_path/../Frameworks then you could link the Wish
executable against that embedded library and get a Wish that worked.  But
you could not link X.dylib against that embedded library and get an X.dylib
that worked, because it needs a relative path that starts with @loader_path.

What I think is the correct approach is to have the LC_ID_DYLIB path be
@rpath/Tcl.  That would work in all situations, but it would require that
you pay attention and make sure that you set the correct RPATH for the
binary that you are linking.  In particular, if you are linking an
executable then the RPATH would need to start with @executable_path and if
you were linking X.dylib then it would need to start with @loader_path.

- Marc

It is used when you link against the library and it becomes the LC

On Mon, Apr 12, 2021 at 1:23 PM Kevan Hashemi <ha...@br...> wrote:

> Dear Marc,
>
> > Do you have permission to write to the file?
>
> Good call. With "sudo" I can re-write the ID of the Tcl library.
>
> > Then you need to change the LC_LOAD_DYLIB for X.dylib to be a correct
> path to the Tcl library
>
> Yes, I'm doing that in my Makefile and it works fine.
>
> > Because Tcl is normally installed in /Library/Frameworks/Tcl.framework
> and
> > Tk is normally installed in /Library/Frameworks/Tk.framework.  So it is
> > appropriate for them to have absolute LC_ID_DYLIB paths.
>
> Okay. But the Tk library has a relative path, and every previous version
> of the Tcl and Tk have had relative paths, and the Wish embedded executable
> should not call the frameworks installed in /Library because the embedded
> Wish is supposed to call its own frameworks, which requires a relative
> path. Therefore, I claim that the /Library version of LD_ID_DYLIB for the
> Tcl framework in the embedded version of Wish is an error.
>
> Cheers, Kevan
>
> --
> Kevan Hashemi, Electrical Engineer
> Physics Department, Brandeis University
> http://www.bndhep.net
>

Re: [MACTCL] Mach-O ID of Tcl 8.7a3 Library

[Kevan H. <ha...@br...>]

Dear Marc,

> Do you have permission to write to the file?

Good call. With "sudo" I can re-write the ID of the Tcl library.

> Then you need to change the LC_LOAD_DYLIB for X.dylib to be a correct path to the Tcl library

Yes, I'm doing that in my Makefile and it works fine.

> Because Tcl is normally installed in /Library/Frameworks/Tcl.framework and
> Tk is normally installed in /Library/Frameworks/Tk.framework.  So it is
> appropriate for them to have absolute LC_ID_DYLIB paths.

Okay. But the Tk library has a relative path, and every previous version of the Tcl and Tk have had relative paths, and the Wish embedded executable should not call the frameworks installed in /Library because the embedded Wish is supposed to call its own frameworks, which requires a relative path. Therefore, I claim that the /Library version of LD_ID_DYLIB for the Tcl framework in the embedded version of Wish is an error.

Cheers, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] Mach-O ID of Tcl 8.7a3 Library

[Mansour M. <man...@gm...>]

On Mon, Apr 12, 2021 at 1:29 PM Kevan Hashemi <ha...@br...> wrote:

> kevan@KSH5 Tcl % install_name_tool -id \
>         @executable_path/../Frameworks/Tcl.framework/Versions/8.6/Tcl Tcl
> /Library/Developer/CommandLineTools/usr/bin/install_name_tool: fatal error: the __LINKEDIT segment
> does not cover the end of the file (can't be processed) in: Tcl

The binary might be corrupted, I think you should rebuild it.

> Load command 13
>            cmd LC_LOAD_DYLIB
>        cmdsize 88
>           name @executable_path/../Frameworks/Tcl.framework/Versions/8.7/Tcl (offset 24)
>     time stamp 2 Wed Dec 31 19:00:02 1969
>        current version 8.7.0
> compatibility version 8.7.0
>
> When my X.dylib is called, it demands that Wish find the following library, regardless of the LC_LOAD_DYLIB fields present in the Wish executable.
>
> /Library/Frameworks/Tcl.framework/Versions/8.7/Tcl

You might want to use run-time search paths (rpaths), like so:

$ install_name_tool -change
"@executable_path/../Frameworks/Tcl.framework/Versions/8.7/Tcl"
"@rpath/../Frameworks/Tcl.framework/Versions/8.7/Tcl" /path/to/X.dylib
$ install_name_tool -change
"/Library/Frameworks/Tcl.framework/Versions/8.7/Tcl"
"@rpath/../Frameworks/Tcl.framework/Versions/8.7/Tcl" /path/to/X.dylib
$ install_name_tool -add_rpath "@loader_path" /path/to/X.dylib

You might need to do this to both X.dylib and your executable.

Re: [MACTCL] Mach-O ID of Tcl 8.7a3 Library

[Marc C. <mar...@gm...>]

On Mon, Apr 12, 2021 at 12:28 PM Kevan Hashemi <ha...@br...> wrote:

> Dear Marc,
>
> Thank you for your attention, responses to your comments below. For other
> readers, my question is this: Why does the 8.7a3 Tcl library have an
> absolute path for its LC_ID_DYLIB rather than a relative path?
>

Because Tcl is normally installed in /Library/Frameworks/Tcl.framework and
Tk is normally installed in /Library/Frameworks/Tk.framework.  So it is
appropriate for them to have absolute LC_ID_DYLIB paths.

> To change the LC_ID_DYLIB path with install_name_tool you should use the
> -id option.
>
> That does not work, sadly, I get this error:
>
> kevan@KSH5 Tcl % install_name_tool -id \
>         @executable_path/../Frameworks/Tcl.framework/Versions/8.6/Tcl Tcl
> /Library/Developer/CommandLineTools/usr/bin/install_name_tool: fatal
> error: the __LINKEDIT segment
> does not cover the end of the file (can't be processed) in: Tcl
>

> It looks like the text segment that holds the ID path is not large enough
> to contain the extended string of the relative path.
>

No, that is not what that means.  It almost certainly means that there is a
zipfile appended to your Tcl library.  That breaks the structure of the
LINKEDIT segment for the reason that the error message says.  That has now
been fixed.  The macher tool is now being used to put the zipfile into the
Tcl library by making the library into a fat binary, the last -arch being
an unspecified architecture which can be legally used to hold the
zipfile.   You need to use the current core-8-branch tip instead of the
older source code that you are using.

> So what you need to do is to change (or add) an LC_LOAD_DYLIB path in the
> main executable of your app so that it will do that.
>
> This would be a change to the Wish executable, this being the only
> executable that is executed. The Wish executable already has LC_LOAD_DYLIB
> for Tcl:
>
> Load command 13
>            cmd LC_LOAD_DYLIB
>        cmdsize 88
>           name
> @executable_path/../Frameworks/Tcl.framework/Versions/8.7/Tcl (offset 24)
>     time stamp 2 Wed Dec 31 19:00:02 1969
>        current version 8.7.0
> compatibility version 8.7.0
>

That looks correct to me, except for the timestamp.

> When my X.dylib is called, it demands that Wish find the following
> library, regardless of the LC_LOAD_DYLIB fields present in the Wish
> executable.
>
> /Library/Frameworks/Tcl.framework/Versions/8.7/Tcl
>

Then you need to change the LC_LOAD_DYLIB for X.dylib to be a correct path
to the Tcl library, starting with @loader_path if you want it to be
relative to the location of X.dylib.  (@executable is only for executables,
not libraries).  Alternatively, you can set an RPATH, which is also allowed
to be relative.

> Sounds like a useful thing to have on my hard driver, thank you. I
> downloaded and tried to change the id of my Tcl library:
>
> kevan@KSH5 8.7 % ~/Desktop/macher set_id
> @executable_path/../Frameworks/Tcl.framework/Versions/8.7/Tcl Tcl
> Could not open mach-o file Tcl
>

Do you have permission to write to the file?  Is it a real Mach-O file (as
opposed to a symlink, for example).

- Marc

Re: [MACTCL] Mach-O ID of Tcl 8.7a3 Library

[Kevan H. <ha...@br...>]

Dear Marc,

Thank you for your attention, responses to your comments below. For other readers, my question is this: Why does the 8.7a3 Tcl library have an absolute path for its LC_ID_DYLIB rather than a relative path?

> To change the LC_ID_DYLIB path with install_name_tool you should use the -id option. 

That does not work, sadly, I get this error:

kevan@KSH5 Tcl % install_name_tool -id \
	@executable_path/../Frameworks/Tcl.framework/Versions/8.6/Tcl Tcl
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: fatal error: the __LINKEDIT segment
does not cover the end of the file (can't be processed) in: Tcl

It looks like the text segment that holds the ID path is not large enough to contain the extended string of the relative path.

> But the otool -L command does *not* display the LC_ID_DYLIB path of a Mach file. 

I assumed the first path returned by -L was the same as the LC_ID_DYLIB of -l, because they are the same path. Apologies for confusion caused by my error. But the LC_ID_DYLIB is indeed equal to the absolute path I gave.

> So what you need to do is to change (or add) an LC_LOAD_DYLIB path in the main executable of your app so that it will do that. 

This would be a change to the Wish executable, this being the only executable that is executed. The Wish executable already has LC_LOAD_DYLIB for Tcl:

Load command 13
           cmd LC_LOAD_DYLIB
       cmdsize 88
          name @executable_path/../Frameworks/Tcl.framework/Versions/8.7/Tcl (offset 24)
    time stamp 2 Wed Dec 31 19:00:02 1969
       current version 8.7.0
compatibility version 8.7.0

When my X.dylib is called, it demands that Wish find the following library, regardless of the LC_LOAD_DYLIB fields present in the Wish executable.

/Library/Frameworks/Tcl.framework/Versions/8.7/Tcl

> I find it a pain to use otool and install_name_tool and that is why I wrote the utility "macher" 

Sounds like a useful thing to have on my hard driver, thank you. I downloaded and tried to change the id of my Tcl library:

kevan@KSH5 8.7 % ~/Desktop/macher set_id @executable_path/../Frameworks/Tcl.framework/Versions/8.7/Tcl Tcl
Could not open mach-o file Tcl

Best, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] Mach-O ID of Tcl 8.7a3 Library

[Marc C. <mar...@gm...>]

Hi Kevan,

Mach-O .dylib files can be used either as shared libraries or as link
libraries.  The LC_ID_DYLIB path is used *only* when you are linking an
executable against the Tcl library, so as to make the executable use the
Tcl library as a shared library.  In that case the executable will acquire
an LC_LOAD_DYLIB path which is the same as the LC_ID_DYLIB path in the Tcl
library.  To change the LC_ID_DYLIB path with install_name_tool you should
use the -id option.  The path that you provide as the value for that option
will become the LC_ID_DYLIB path.  But the otool -L command does *not*
display the LC_ID_DYLIB path of a Mach file.  It displays the LC_LOAD_DYLIB
paths.  And probably the LC_ID_DYLIB path is not your  problem.

You probably linked the main executable of your app against the Tcl library
and you want it to dynamically load the Tcl library.  So what you need to
do is to change (or add) an LC_LOAD_DYLIB path in the main executable of
your app so that it will do that.  The LC_LOAD_DYLIB path that you want
will probably look like
@executable_path/../Frameworks/Tcl.framework/Versions/Current/Tcl.  To do
that with install_name_tool you need to use the -change option, not the -id
option.

I find it a pain to use otool and install_name_tool and that is why I wrote
the utility "macher" which is much more to my taste and can do some things
which are required by Tcl and Tk (now that they support zipfs
singe-file-executables) and which are not available from Apple's tools.
You can download macher from https://github.com/culler/macher/releases .

- Marc

On Sun, Apr 11, 2021 at 10:31 PM Kevan Hashemi <ha...@br...> wrote:

> Greetings,
>
> I compiled the TclTk 8.7a3 embedded Wish shell on MacOS 10.12 (still
> working on getting it to compile on my 10.15 machine). I am delighted with
> its performance. I did encounter one obstacle. In the tcl.framework
> directory we have:
>
> kevan@KSH5 8.7 % otool -L Tcl
> Tcl:
>         /Library/Frameworks/Tcl.framework/Versions/8.7/Tcl (compatibility
> version 8.7.0, current version 8.7.0)
> <snip>
>
> This first line is the Mach-O LC_ID_DYLIB path. Compare to the same path
> for an earlier version of TclTk:
>
> kevan@KSH5 8.6 % otool -L Tcl
> Tcl:
>         @executable_path/../Frameworks/Tcl.framework/Versions/8.6/Tcl
> (compatibility version 8.6.0, current version 8.6.10)
> <snip>
>
> Suppose our embedded Wish shell loads a dynamic library X.dylib. In order
> for X.dylib to install commands into the Tcl interpreter, it must have
> previously been compiled and linked to the Tcl framework. When Wish loads
> X.dylib with the "load" command, it tries to make sure that all libraries
> that X.dylib depends upon are also loaded. So Wish will look for the
> dependent Tcl library in the LC_ID_DYLIB path provided by the Tcl library
> when X.dylib was created. In the case of Tcl 8.7, LC_ID_DYLIB points to a
> non-existent library. In the case of 8.6, LC_ID_DYLIB provids a relative
> path that locates the same Tcl library used by the Wish shell itself.
>
> I have been unable to change LC_ID_DYLIB in the Tcl library with
> install_name_tool, but we can change the path to the Tcl library that is
> recorded in X.dylib, like this:
>
> install_name_tool -change \
>    /Library/Frameworks/Tcl.framework/Versions/8.7/Tcl \
>    @executable_path/../Frameworks/Tcl.framework/Versions/8.7/Tcl \
>    X.dylib
>
> Now Wish can load X.dylib. Meanwhile, the Tk 8.7 library does not have
> this problem: it provides the traditional relative path for LD_ID_DYLIB.
>
> So, I have a fix, which I have automated in my Makefile, but I'm wondering
> if this is something that should be set right in the configure script.
>
> Best, Kevan
>
> --
> Kevan Hashemi, Electrical Engineer
> Physics Department, Brandeis University
> http://www.bndhep.net
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

[MACTCL] Mach-O ID of Tcl 8.7a3 Library

[Kevan H. <ha...@br...>]

Greetings,

I compiled the TclTk 8.7a3 embedded Wish shell on MacOS 10.12 (still working on getting it to compile on my 10.15 machine). I am delighted with its performance. I did encounter one obstacle. In the tcl.framework directory we have:

kevan@KSH5 8.7 % otool -L Tcl
Tcl:
	/Library/Frameworks/Tcl.framework/Versions/8.7/Tcl (compatibility version 8.7.0, current version 8.7.0)
<snip>

This first line is the Mach-O LC_ID_DYLIB path. Compare to the same path for an earlier version of TclTk:

kevan@KSH5 8.6 % otool -L Tcl
Tcl:
	@executable_path/../Frameworks/Tcl.framework/Versions/8.6/Tcl (compatibility version 8.6.0, current version 8.6.10)
<snip>

Suppose our embedded Wish shell loads a dynamic library X.dylib. In order for X.dylib to install commands into the Tcl interpreter, it must have previously been compiled and linked to the Tcl framework. When Wish loads X.dylib with the "load" command, it tries to make sure that all libraries that X.dylib depends upon are also loaded. So Wish will look for the dependent Tcl library in the LC_ID_DYLIB path provided by the Tcl library when X.dylib was created. In the case of Tcl 8.7, LC_ID_DYLIB points to a non-existent library. In the case of 8.6, LC_ID_DYLIB provids a relative path that locates the same Tcl library used by the Wish shell itself.

I have been unable to change LC_ID_DYLIB in the Tcl library with install_name_tool, but we can change the path to the Tcl library that is recorded in X.dylib, like this:

install_name_tool -change \
   /Library/Frameworks/Tcl.framework/Versions/8.7/Tcl \
   @executable_path/../Frameworks/Tcl.framework/Versions/8.7/Tcl \
   X.dylib

Now Wish can load X.dylib. Meanwhile, the Tk 8.7 library does not have this problem: it provides the traditional relative path for LD_ID_DYLIB.

So, I have a fix, which I have automated in my Makefile, but I'm wondering if this is something that should be set right in the configure script.

Best, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] package Img problem after OSX/Img upgrades

[Christopher C. <chr...@gm...>]

> The useful "image create photo -format window -data <canvasID>" command causes Wish to quit unexpectedly after upgrading to a new Macbook and current releases.
> 
> The current platform consists of OSX 10.15.7 (Catalina), Tcl/Tk 8.6.11 (built locally per the instructions in Tcl-Tk_8.6.11/tk8.6.11/macosx/README *), and tkImg 1.4.13 (binary distribution from Img1.4.13-Darwin64.tar.gz on SourceForge **). 
> 
> The previous platform, where the canvas-to-image command used to work, consisted of a mid-2012 Macbook running 10.14.6 (Mojave), ActiveTcl 8.6.9, and Img 1.4.6.
> 
> On the current platform, most of tkImg 1.4.13 seems to work.  A test/demo script in the source distribution, /Img-1.4.13/demo.tcl, executes without any obvious flaw for all file formats that are supported as delivered.  The only problem observed arises with the "-format window" option for creating a photo image from a displayed canvas.
…
> Executing the last test script line, "image create photo -format window -data $c" causes Wish to quit with no error report.
> 
> Did I miss some configuration or installation step?
> 
> Peter Martin


Hello Peter,

Your issue sounds closely related to the one I discuss in the more recent comments of this ticket: https://core.tcl-lang.org/tk/info/685ac30727 . I left a comment attempting to explain why this crash occurs. But the bigger remaining problem is that capturing a window has been broken for the past few Tk Aqua releases, although I thought 8.6.9 and possibly anyone using macOS 10.14 and later would've been affected, and I currently only know of a good way this might be fixed for macOS 10.13 and earlier.

Christopher A. Chavez

[MACTCL] package Img problem after OSX/Img upgrades

[Peter M. <pm...@ma...>]

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    The useful "image create photo -format window -data
    &lt;canvasID&gt;" command causes Wish to quit unexpectedly after
    upgrading to a new Macbook and current releases. <br>
    <br>
    The current platform consists of OSX 10.15.7 (Catalina), Tcl/Tk
    8.6.11 (built locally per the instructions in
    Tcl-Tk_8.6.11/tk8.6.11/macosx/README *), and tkImg 1.4.13 (binary
    distribution from Img1.4.13-Darwin64.tar.gz on SourceForge **).  <br>
    <br>
    The previous platform, where the canvas-to-image command used to
    work, consisted of a mid-2012 Macbook running 10.14.6 (Mojave),
    ActiveTcl 8.6.9, and Img 1.4.6.<br>
    <br>
    On the current platform, most of tkImg 1.4.13 seems to work.  A
    test/demo script in the source distribution, /Img-1.4.13/demo.tcl,
    executes without any obvious flaw for all file formats that are
    supported as delivered.  The only problem observed arises with the
    "-format window" option for creating a photo image from a displayed
    canvas.<br>
    <br>
    <br>
    *      To prevent Tcl/Tk build-time errors, <br>
           CFLAGS="-arch i386 -arch x86_64 -arch ppc
    -mmacosx-version-min=10.5"<br>
    was defined in the shell as:<br>
           CFLAGS="-arch x86_64 -mmacosx-version-min=10.5"<br>
    <br>
    **    To overcome OSX security blockages at first use, presumably
    due to an unrecognized developer, admin permissions were applied to
    each of the tkImg .dylib files using a "Security &amp; Privacy"
    feature in System Preferences.  Is this because the binaries for Mac
    OSX are not "notarized," as Apple requires for OSX releases starting
    with version 10.15?<br>
    <br>
        My test script, run in a Wish console session:<br>
    <br>
    clock format [clock seconds] -format {%d-%b-%Y %T}<br>
    package require Img<br>
    set w [toplevel .top]<br>
    set c [canvas $w.c -height 40 -width 60]<br>
    pack $c<br>
    $c create rectangle 10 10 30 30 -fill green<br>
    update<br>
    image create photo -format window -data $c<br>
    <br>
    <br>
        My log, up to the last line of the test script:<br>
    <br>
    () 1 % clock format [clock seconds] -format {%d-%b-%Y %T}<br>
    09-Apr-2021 09:58:06<br>
    () 2 % set tcl_patchLevel<br>
    8.6.11<br>
    () 3 % set ::env(DISPLAY)<br>
    /private/tmp/com.apple.launchd.u4wW7NfgAh/org.macosforge.xquartz:0<br>
    () 4 % package require Img<br>
    1.4.13<br>
    () 5 % set w [toplevel .top]<br>
    .top<br>
    () 6 % set c [canvas $w.c -height 40 -width 60]<br>
    .top.c<br>
    () 7 % pack $c<br>
    () 8 % $c create rectangle 10 10 30 30 -fill green<br>
    1<br>
    () 9 % update<br>
    <br>
    Executing the last test script line, "image create photo -format
    window -data $c" causes Wish to quit with no error report.<br>
    <br>
    <br>
    Did I miss some configuration or installation step?<br>
    <br>
    Peter Martin<br>
    <br>
  </body>
</html>

Re: [MACTCL] trouble building tcl/tk from source (macOS 10.15.6, Xcode 12.4) --> strtoul() issue???

[Kevan H. <ha...@br...>]

> I'm going to try the build on my previous laptop, where the compile worked a year ago.

On a MacOS 10.12.6 machine with Apple LLVM version 9.0.9, I build TclTk 8.7a3 with:

export CFLAGS="-arch x86_64 -mmacosx-version-min=10.9"
make -C tcl/macosx embedded
make -C tk/macosx embedded

The build completes just fine. I have a working 8.7a3 Wish shell.

There appears to be something wrong with my MacOS 10.15.7 gcc:

KSH5:~ kevan$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Best, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] Bitmap not supported?

[Jasper T. <ja...@si...>]

Sorry, it looks like I have to compile and install bitmap support separately — please ignore this report. I’ll assume the source file I mentioned is for X bitmap (.xbm) support.
	—Jasper

> On 6 Apr 2021, at 13:49, Kevin Walzer <kw...@co...> wrote:
> 
> On 4/6/21 8:12 AM, Jasper Taylor wrote:
>> I just built TclTk 8.6.11 on a Mac mini M1 and the photo handling commands report that bitmap (.bmp) format is no longer supported. The file generic/tkImgBmap.c seems to provide bitmap support so what is going wrong?
>> 	Jasper
> 
> 
> This works fine for me with 8.6.11 on Intel:
> 
> image create bitmap xbm_video_32 -data {
> 
> #define xbm_video_32_width 32
> #define xbm_video_32_height 32
> static char xbm_video_32_bits[] = {
>   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>   0x01, 0xFF, 0xFF, 0xFF, 0x03, 0xFF, 0xFF, 0xFF, 0x0F, 0xFF, 0xFF, 0xFF,
>   0x1F, 0xFF, 0xFF, 0xFF, 0x3F, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
>   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
>   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
>   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
>   0x3F, 0xFF, 0xFF, 0xFF, 0x1F, 0xFF, 0xFF, 0xFF, 0x0F, 0xFF, 0xFF, 0xFF,
>   0x03, 0xFF, 0xFF, 0xFF, 0x01, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00,
>   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, };
> 
> 
> }
> 
> pack [label .l -image xbm_video_32]
> 
> Can't speak to Apple Silicon as I don't have a machine with that processor.
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> 
> 
> 
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

Re: [MACTCL] Bitmap not supported?

[Kevin W. <kw...@co...>]

On 4/6/21 8:12 AM, Jasper Taylor wrote:
> I just built TclTk 8.6.11 on a Mac mini M1 and the photo handling commands report that bitmap (.bmp) format is no longer supported. The file generic/tkImgBmap.c seems to provide bitmap support so what is going wrong?
> 	Jasper


This works fine for me with 8.6.11 on Intel:

image create bitmap xbm_video_32 -data {

#define xbm_video_32_width 32
#define xbm_video_32_height 32
static char xbm_video_32_bits[] = {
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x01, 0xFF, 0xFF, 0xFF, 0x03, 0xFF, 0xFF, 0xFF, 0x0F, 0xFF, 0xFF, 0xFF,
   0x1F, 0xFF, 0xFF, 0xFF, 0x3F, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
   0x3F, 0xFF, 0xFF, 0xFF, 0x1F, 0xFF, 0xFF, 0xFF, 0x0F, 0xFF, 0xFF, 0xFF,
   0x03, 0xFF, 0xFF, 0xFF, 0x01, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, };


}

pack [label .l -image xbm_video_32]

Can't speak to Apple Silicon as I don't have a machine with that processor.

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[MACTCL] Bitmap not supported?

[Jasper T. <ja...@si...>]

I just built TclTk 8.6.11 on a Mac mini M1 and the photo handling commands report that bitmap (.bmp) format is no longer supported. The file generic/tkImgBmap.c seems to provide bitmap support so what is going wrong?
	Jasper

Re: [MACTCL] trouble building tcl/tk from source (macOS 10.15.6, Xcode 12.4) --> strtoul() issue???

[Kevan H. <ha...@br...>]

Mansour:

> CGPathCreateWithRoundedRect is only available with 10.9 and above:
> 
> https://developer.apple.com/documentation/coregraphics/1411218-cgpathcreatewithroundedrect
> 
> The simplest solution is to set MACOSX_DEPLOYMENT_TARGET to 10.9.

The Tk compile completes when I move up to 10.9.

> The other solution is as follows...

Thank you for this. I will keep a note of the patch in case I need to run on a 10.8 machine. In the meantime, I believe all my users are running 10.11 or later.

Marc:

> To build for a 10.8 target I run:
> export CFLAGS="-mmacosx-version-min=10.9"

I try the following with TclTk 8.6.10:

export CFLAGS="-mmacosx-version-min=10.9"
make -C tcl/macosx embedded
make -C tk/macosx embedded

And as you predicted, I encounter no problems in the compilation. But I still get this same error when linking Tk.

Undefined symbols for architecture x86_64:
   "_TclIsSpaceProc", referenced from:
       _strtoul in libtclstub8.6.a(strtoul.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I get the same error when I try to build TclTk 8.7a3 with the same commands, and if I try without "embedded". If I add "-arch x86_64" to CFLAGS, the result is the same. The fact that _TclIsSpaceProc is not available is not because I compiled a 32-bit version of the routine.

> Please make sure that you completely remove your build directory before
> compiling. 

I have been doing that every time, deleting the entire build directory.

Now I try building 10.7a3 with:

export CFLAGS="-mmacosx-version-min=10.15"
make -C tcl/macosx embedded
make -C tk/macosx embedded

I get the same _TclIsSpaceProc link error. According to a web search, this error was reported about six months ago in various forms, and was occuring with XCode command line tools version 12. I don't have XCode, only the CLTs. I have Clang version 12.0.0. I'm going to try the build on my previous laptop, where the compile worked a year ago.

Best, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] trouble building tcl/tk from source (macOS 10.15.6, Xcode 12.4) --> strtoul() issue???

[Mansour M. <man...@gm...>]

On Sat, Apr 3, 2021 at 9:53 AM Kevan Hashemi <ha...@br...> wrote:

> /Users/kevan/Desktop/Scratch/TclTk/TclTk8.7a3/tk/unix/../macosx/ttkMacOSXTheme.c:408:12: error: implicit declaration of
>        function 'CGPathCreateWithRoundedRect' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
>      path = CGPathCreateWithRoundedRect(bounds, radius, radius, NULL);

CGPathCreateWithRoundedRect is only available with 10.9 and above:

https://developer.apple.com/documentation/coregraphics/1411218-cgpathcreatewithroundedrect

The simplest solution is to set MACOSX_DEPLOYMENT_TARGET to 10.9.

The other solution is as follows.

There is indeed a check for the availability of
CGPathCreateWithRoundedRect in macosx/ttkMacOSXTheme.c, line 122:

    #if MAC_OS_X_VERSION_MAX_ALLOWED >= 1080
    #define CGCOLOR(nscolor) nscolor.CGColor
    #else
    #define CGCOLOR(nscolor) (0 ? (CGColorRef) nscolor : NULL)
    #define CGPathCreateWithRoundedRect(w, x, y, z) NULL
    #endif

But it's looking for the wrong version (10.8 not 10.9).

The check for CGPathCreateWithRoundedRect (10.9+) should be separated
from the check for NSColor.CGColor (10.8+).

Here is a patch:

--- ttkMacOSXTheme.c.orig 2021-04-04 09:58:16.000000000 -0400
+++ ttkMacOSXTheme.c 2021-04-04 09:53:31.000000000 -0400
@@ -123,6 +123,8 @@
 #define CGCOLOR(nscolor) nscolor.CGColor
 #else
 #define CGCOLOR(nscolor) (0 ? (CGColorRef) nscolor : NULL)
+#endif
+#if MAC_OS_X_VERSION_MAX_ALLOWED < 1090
 #define CGPathCreateWithRoundedRect(w, x, y, z) NULL
 #endif

Re: [MACTCL] trouble building tcl/tk from source (macOS 10.15.6, Xcode 12.4) --> strtoul() issue???

[Marc C. <mar...@gm...>]

Hi Kevan,

I am using macOS 11.2 for my build.  To build for a 10.8 target I run:
export CFLAGS="-mmacosx-version-min=10.8"
There is no need to specify an sdk, as far as I know.  The native SDK
should know how to build for any older target systems and  I have never
used the SDKROOT variable.  Unless you have multiple copies of XCode on
your system the only choice you have is between XCode and Command Line
Tools.  And the default value for that choice should work.

Please make sure that you completely remove your build directory before
compiling.  Failure to do that can lead to weird errors like the ones you
are seeing.

- Marc

On Sat, Apr 3, 2021 at 8:53 AM Kevan Hashemi <ha...@br...> wrote:

> Marc, thanks for your suggestion:
>
> > With current tips of core-8-branch and main I do not see these errors
> when
> > I build Tcl 8.7 and Tk 8.7 using my usual build process:
> >
> > make -C tcl/macosx
> > make -C tk/macosx
>
> I tried that last night and it failed on the Tk link in the same way, with
> this previously-reported error:
>
> >>> Undefined symbols for architecture x86_64:
> >>>     "_TclIsSpaceProc", referenced from:
> >>>         _strtoul in libtclstub8.7.a(strtoul.o)
> >>> ld: symbol(s) not found for architecture x86_64
> >>> clang: error: linker command failed with exit code 1 (use -v to see
> >> invocation)
>
> Mansour, thank you for this cool use of xcrun:
>
> > Try setting these environment variables instead:
> >
> >      export CFLAGS="-arch x86_64"
> >      export MACOSX_DEPLOYMENT_TARGET="10.8"
> >      export SDKROOT="$(xcrun --sdk macosx10.8 --show-sdk-path)"
> >
> > MACOSX_DEPLOYMENT_TARGET and SDKROOT are equivalent to
> > -mmacosx-version-min and -isysroot, respectively, but are used by both
> > the compiler and linker.
>
> I tried this and I get a Tk compile error
>
> /Users/kevan/Desktop/Scratch/TclTk/TclTk8.7a3/tk/unix/../macosx/ttkMacOSXTheme.c:408:12:
> error: implicit declaration of
>        function 'CGPathCreateWithRoundedRect' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
>      path = CGPathCreateWithRoundedRect(bounds, radius, radius, NULL);
>
> Which lookis like a C dialect error. I have gcc version:
>
> KSH5:TclTk8.7a3 kevan$ gcc --version
> Configured with: --prefix=/Library/Developer/CommandLineTools/usr
> --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.8.sdk/usr/include/c++/4.2.1
> Apple clang version 12.0.0 (clang-1200.0.32.2)
> Target: x86_64-apple-darwin19.6.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>
> What version of MacOS are you both using? Perhaps mine needs to be updated.
>
> Best, Kevan
>
> --
> Kevan Hashemi, Electrical Engineer
> Physics Department, Brandeis University
> http://www.bndhep.net
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] trouble building tcl/tk from source (macOS 10.15.6, Xcode 12.4) --> strtoul() issue???

[Kevan H. <ha...@br...>]

Marc, thanks for your suggestion:

> With current tips of core-8-branch and main I do not see these errors when
> I build Tcl 8.7 and Tk 8.7 using my usual build process:
> 
> make -C tcl/macosx
> make -C tk/macosx

I tried that last night and it failed on the Tk link in the same way, with this previously-reported error:

>>> Undefined symbols for architecture x86_64:
>>>     "_TclIsSpaceProc", referenced from:
>>>         _strtoul in libtclstub8.7.a(strtoul.o)
>>> ld: symbol(s) not found for architecture x86_64
>>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)

Mansour, thank you for this cool use of xcrun:

> Try setting these environment variables instead:
> 
>      export CFLAGS="-arch x86_64"
>      export MACOSX_DEPLOYMENT_TARGET="10.8"
>      export SDKROOT="$(xcrun --sdk macosx10.8 --show-sdk-path)"
> 
> MACOSX_DEPLOYMENT_TARGET and SDKROOT are equivalent to
> -mmacosx-version-min and -isysroot, respectively, but are used by both
> the compiler and linker.

I tried this and I get a Tk compile error

/Users/kevan/Desktop/Scratch/TclTk/TclTk8.7a3/tk/unix/../macosx/ttkMacOSXTheme.c:408:12: error: implicit declaration of
       function 'CGPathCreateWithRoundedRect' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
     path = CGPathCreateWithRoundedRect(bounds, radius, radius, NULL);

Which lookis like a C dialect error. I have gcc version:

KSH5:TclTk8.7a3 kevan$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.8.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

What version of MacOS are you both using? Perhaps mine needs to be updated.

Best, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

Re: [MACTCL] trouble building tcl/tk from source (macOS 10.15.6, Xcode 12.4) --> strtoul() issue???

[Mansour M. <man...@gm...>]

On Thu, Apr 1, 2021 at 12:57 PM Kevan Hashemi <ha...@br...> wrote:

> export CFLAGS="-arch x86_64 \
>         -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.8.sdk \
>         -mmacosx-version-min=10.8"
> make -C tcl/macosx embedded
> make -C tk/macosx embedded

The CFLAGS environment variable is only used by the compiler, not the linker.

Try setting these environment variables instead:

    export CFLAGS="-arch x86_64"
    export MACOSX_DEPLOYMENT_TARGET="10.8"
    export SDKROOT="$(xcrun --sdk macosx10.8 --show-sdk-path)"

MACOSX_DEPLOYMENT_TARGET and SDKROOT are equivalent to
-mmacosx-version-min and -isysroot, respectively, but are used by both
the compiler and linker.

Re: [MACTCL] trouble building tcl/tk from source (macOS 10.15.6, Xcode 12.4) --> strtoul() issue???

[Marc C. <mar...@gm...>]

With current tips of core-8-branch and main I do not see these errors when
I build Tcl 8.7 and Tk 8.7 using my usual build process:

make -C tcl/macosx
make -C tk/macosx

So it would seem that this is an issue with the current configure script
which does not arise when using the GNUmakefile in each of the two macosx
directories.

- Marc

On Thu, Apr 1, 2021 at 11:57 AM Kevan Hashemi <ha...@br...> wrote:

> Dear Uwe,
>
> I'm having the same trouble as you.
>
> > I put both tcl8.7a3 and tk8.7a3 in a common subdir tcltk8.7a3 and
> renamed both source trees to tcl and tk, respectively
>
> I just did the same thing on MacOS 10.15.7
>
> > tcl builds OK with:
> >
> > cd tcl/macosx
> > ./configure
> > make
>
> Here I do the following to make an embedded verion of TclTk 8.7a3:
>
> export CFLAGS="-arch x86_64"
> make -C tcl/macosx embedded
> make -C tk/macosx embedded
>
> > tk compiles OK with the corresponding command sequence but fails to link:
> >
> > Undefined symbols for architecture x86_64:
> >    "_TclIsSpaceProc", referenced from:
> >        _strtoul in libtclstub8.7.a(strtoul.o)
> > ld: symbol(s) not found for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> I get the same error.
>
> > BTW, the same happens when I try to build tcl/tk 8.6.10 from the command
> line.
>
> Same for me.
>
> So, I try linking against an older SDK, which I have on my hard driver, to
> generate an executable that will run on MacOS 10.8+. This worked before I
> updated from an earlier version of MacOS 10.15 to my current 10.15.7.
>
> export CFLAGS="-arch x86_64 \
>         -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.8.sdk \
>         -mmacosx-version-min=10.8"
> make -C tcl/macosx embedded
> make -C tk/macosx embedded
>
> The Tk build fails with a compiler error:
>
> macosx/ttkMacOSXTheme.c:1097:22: error: implicit declaration of function
> 'CGPathCreateWithRoundedRect' is
>        invalid in C99 [-Werror,-Wimplicit-function-declaration]
>      CGPathRef path = CGPathCreateWithRoundedRect(insetBounds, 4, 4, NULL);
>
> I try using the 10.15 SDK to make a 10.15+ executable and the Tk link
> fails with the same error you show above. Six months ago I compiled 8.6.10
> and 8.6.11 multiple times for MacOS 10.8, 10.9, etc. with no problems. But
> that was before I installed the 10.15.7 update.
>
> Best, Kevan
>
> --
> Kevan Hashemi, Electrical Engineer
> Physics Department, Brandeis University
> http://www.bndhep.net
>
>
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

Re: [MACTCL] trouble building tcl/tk from source (macOS 10.15.6, Xcode 12.4) --> strtoul() issue???

[Kevan H. <ha...@br...>]

Dear Uwe,

I'm having the same trouble as you.

> I put both tcl8.7a3 and tk8.7a3 in a common subdir tcltk8.7a3 and renamed both source trees to tcl and tk, respectively

I just did the same thing on MacOS 10.15.7

> tcl builds OK with:
> 
> cd tcl/macosx
> ./configure
> make

Here I do the following to make an embedded verion of TclTk 8.7a3:

export CFLAGS="-arch x86_64"
make -C tcl/macosx embedded
make -C tk/macosx embedded

> tk compiles OK with the corresponding command sequence but fails to link:
> 
> Undefined symbols for architecture x86_64:
>    "_TclIsSpaceProc", referenced from:
>        _strtoul in libtclstub8.7.a(strtoul.o)
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)

I get the same error.

> BTW, the same happens when I try to build tcl/tk 8.6.10 from the command line.

Same for me.

So, I try linking against an older SDK, which I have on my hard driver, to generate an executable that will run on MacOS 10.8+. This worked before I updated from an earlier version of MacOS 10.15 to my current 10.15.7.

export CFLAGS="-arch x86_64 \
	-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.8.sdk \
	-mmacosx-version-min=10.8"
make -C tcl/macosx embedded
make -C tk/macosx embedded

The Tk build fails with a compiler error:

macosx/ttkMacOSXTheme.c:1097:22: error: implicit declaration of function 'CGPathCreateWithRoundedRect' is
       invalid in C99 [-Werror,-Wimplicit-function-declaration]
     CGPathRef path = CGPathCreateWithRoundedRect(insetBounds, 4, 4, NULL);

I try using the 10.15 SDK to make a 10.15+ executable and the Tk link fails with the same error you show above. Six months ago I compiled 8.6.10 and 8.6.11 multiple times for MacOS 10.8, 10.9, etc. with no problems. But that was before I installed the 10.15.7 update.

Best, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://www.bndhep.net

[MACTCL] trouble building tcl/tk from source (macOS 10.15.6, Xcode 12.4) --> strtoul() issue???

[Uwe K. <Uwe...@gm...>]

Hello Tcl’ers
I have tried to build tcl/tk 8.7a3 from the command line (doesn’t build out-of-the-box from .xcodeproj at all)

I put both tcl8.7a3 and tk8.7a3 in a common subdir tcltk8.7a3 and renamed both source trees to tcl and tk, respectively

tcl builds OK with:

cd tcl/macosx
./configure
make

tk compiles OK with the corresponding command sequence but fails to link:

Undefined symbols for architecture x86_64:
  "_TclIsSpaceProc", referenced from:
      _strtoul in libtclstub8.7.a(strtoul.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I understand why this happens (and I worked around it by hacking the compat/strtoul.c to not include a reference to TclIsSpaceProc. But that’s just a hack.

I wondered why compat/strtoul.c was included in the build in the first place and I checked config.log. I found that the test for a useable strtoul routine failed abnormally (due to a missing prototype for the exit() function). Similar things happen in several places across the configure process, making the result unrelieable.

Any ideas what might have gone wrong? The configure script should have activated the _ISOC99_SOURCE flag which would have pulled in stdlib.h, shouldn’t it?

BTW, the same happens when I try to build tcl/tk 8.6.10 from the command line.


Best regards,
Uwe



Here is the snippet from config.log:

configure:8841: checking proper strtoul implementation
configure:8857: gcc -o conftest -pipe     -headerpad_max_install_names -Wl,-search_paths_first  conftest.c -lz  -lpthread -framework CoreFoundation >&5
conftest.c:72:16: warning: incompatible redeclaration of library function 'strtoul' [-Wincompatible-library-redeclaration]
    extern int strtoul();
               ^
conftest.c:72:16: note: 'strtoul' is a builtin with type 'unsigned long (const char *, char **, int)'
conftest.c:74:5: error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration]
    exit(strtoul(string,&term,0) != 0 || term != string+1);
    ^
conftest.c:74:5: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
1 warning and 1 error generated.
configure:8857: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "tcl"
| #define PACKAGE_TARNAME "tcl"
| #define PACKAGE_VERSION "8.7"
| #define PACKAGE_STRING "tcl 8.7"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_STDBOOL_H 1
| #define HAVE_SYS_PARAM_H 1
| #define TCL_CFGVAL_ENCODING "iso8859-1"
| #define _REENTRANT 1
| #define _THREAD_SAFE 1
| #define HAVE_PTHREAD_ATTR_SETSTACKSIZE 1
| #define HAVE_PTHREAD_ATFORK 1
| #define HAVE_DECL_PTHREAD_MUTEX_RECURSIVE 1
| #define HAVE_ZLIB 1
| #define MODULE_SCOPE extern __attribute__((__visibility__("hidden")))
| #define HAVE_HIDDEN 1
| #define MAC_OSX_TCL 1
| #define HAVE_COREFOUNDATION 1
| #define HAVE_CAST_TO_UNION 1
| #define TCL_SHLIB_EXT ".dylib"
| #define MP_PREC 4
| #define MP_32BIT 1
| #define TCL_WIDE_INT_IS_LONG 1
| #define HAVE_GETCWD 1
| #define HAVE_MKSTEMP 1
| #define HAVE_OPENDIR 1
| #define HAVE_STRTOL 1
| #define HAVE_WAITPID 1
| #define HAVE_GETNAMEINFO 1
| #define HAVE_GETADDRINFO 1
| #define HAVE_FREEADDRINFO 1
| #define HAVE_GAI_STRERROR 1
| #define HAVE_STRUCT_ADDRINFO 1
| #define HAVE_STRUCT_IN6_ADDR 1
| #define HAVE_STRUCT_SOCKADDR_IN6 1
| #define HAVE_STRUCT_SOCKADDR_STORAGE 1
| #define HAVE_GETPWUID_R_5 1
| #define HAVE_GETPWUID_R 1
| #define HAVE_GETPWNAM_R_5 1
| #define HAVE_GETPWNAM_R 1
| #define HAVE_GETGRGID_R_5 1
| #define HAVE_GETGRGID_R 1
| #define HAVE_GETGRNAM_R_5 1
| #define HAVE_GETGRNAM_R 1
| #define HAVE_MTSAFE_GETHOSTBYNAME 1
| #define HAVE_MTSAFE_GETHOSTBYADDR 1
| #define HAVE_TERMIOS_H 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_SYS_TIME_H 1
| #define TIME_WITH_SYS_TIME 1
| #define HAVE_GMTIME_R 1
| #define HAVE_LOCALTIME_R 1
| #define HAVE_MKTIME 1
| #define HAVE_TM_GMTOFF 1
| #define HAVE_STRUCT_STAT_ST_BLOCKS 1
| #define HAVE_STRUCT_STAT_ST_BLKSIZE 1
| #define HAVE_BLKCNT_T 1
| /* end confdefs.h.  */
| int main() {
|     extern int strtoul();
|     char *term, *string = "0";
|     exit(strtoul(string,&term,0) != 0 || term != string+1);
| }
configure:8867: result: broken

Re: [MACTCL] New background colour for ttk::entry in Tk 8.6.11?

[Torsten B. <be...@ty...>]

Hi,

oh, I should have searched the tickets first. Thanks for pointing me that way. I see the problem and the fix.

ttk::style configure TEntry -background systemTextBackgroundColor 

... does it for me!

Torsten


> Am 05.03.2021 um 14:50 schrieb Christopher Chavez <chr...@gm...>:
> 
> Hello Torsten,
> 
>> when switching from Tcl/Tk 8.6.10 to 8.6.11 I noticed that the background colour of the ttk::entry has changed. It is no longer white but has the same grey as the background of the window (with a narrow white frame around and then the typical narrow darker grey line as in macOS):
> 
> […]
> 
>> Is that the intended behaviour as I do not see this grey background anywhere else in macOS entry fields?
> 
> 
> Another user recently noticed this as well, so I have opened a ticket regarding it: https://core.tcl-lang.org/tk/info/58222c42b3
> It appears to be an unintended regression in 8.6.11.
> 
> Hope this helps,
> Christopher A. Chavez
> 
> 
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac