You can subscribe to this list here.
2001 |
Jan
|
Feb
(20) |
Mar
(29) |
Apr
(10) |
May
(10) |
Jun
(7) |
Jul
(6) |
Aug
(59) |
Sep
(19) |
Oct
(55) |
Nov
(22) |
Dec
(40) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(56) |
Feb
(71) |
Mar
(179) |
Apr
(41) |
May
(26) |
Jun
(52) |
Jul
(62) |
Aug
(19) |
Sep
(87) |
Oct
(188) |
Nov
(95) |
Dec
(30) |
2003 |
Jan
(83) |
Feb
(119) |
Mar
(174) |
Apr
(77) |
May
(85) |
Jun
(52) |
Jul
(67) |
Aug
(121) |
Sep
(147) |
Oct
(96) |
Nov
(89) |
Dec
(144) |
2004 |
Jan
(92) |
Feb
(172) |
Mar
(205) |
Apr
(201) |
May
(105) |
Jun
(42) |
Jul
(94) |
Aug
(109) |
Sep
(81) |
Oct
(59) |
Nov
(84) |
Dec
(68) |
2005 |
Jan
(56) |
Feb
(57) |
Mar
(183) |
Apr
(139) |
May
(131) |
Jun
(178) |
Jul
(62) |
Aug
(42) |
Sep
(95) |
Oct
(47) |
Nov
(73) |
Dec
(47) |
2006 |
Jan
(66) |
Feb
(31) |
Mar
(51) |
Apr
(20) |
May
(49) |
Jun
(26) |
Jul
(23) |
Aug
(65) |
Sep
(67) |
Oct
(26) |
Nov
(16) |
Dec
(8) |
2007 |
Jan
(18) |
Feb
(43) |
Mar
(43) |
Apr
(16) |
May
(33) |
Jun
(48) |
Jul
(34) |
Aug
(7) |
Sep
(9) |
Oct
(55) |
Nov
(44) |
Dec
(73) |
2008 |
Jan
(37) |
Feb
(97) |
Mar
(44) |
Apr
(33) |
May
(79) |
Jun
(11) |
Jul
(66) |
Aug
(9) |
Sep
(12) |
Oct
(6) |
Nov
(12) |
Dec
(19) |
2009 |
Jan
(12) |
Feb
(13) |
Mar
(19) |
Apr
(30) |
May
(59) |
Jun
(22) |
Jul
(11) |
Aug
(59) |
Sep
(82) |
Oct
(25) |
Nov
(51) |
Dec
(27) |
2010 |
Jan
(27) |
Feb
(8) |
Mar
(29) |
Apr
(9) |
May
(39) |
Jun
(6) |
Jul
(8) |
Aug
(22) |
Sep
(33) |
Oct
(8) |
Nov
(35) |
Dec
(9) |
2011 |
Jan
(62) |
Feb
(19) |
Mar
(31) |
Apr
(19) |
May
(1) |
Jun
(1) |
Jul
(17) |
Aug
(10) |
Sep
(14) |
Oct
(11) |
Nov
|
Dec
|
2012 |
Jan
(1) |
Feb
(11) |
Mar
|
Apr
(1) |
May
(5) |
Jun
(7) |
Jul
(22) |
Aug
(22) |
Sep
(30) |
Oct
(23) |
Nov
(19) |
Dec
|
2013 |
Jan
(6) |
Feb
(1) |
Mar
(10) |
Apr
(7) |
May
(3) |
Jun
(3) |
Jul
|
Aug
(3) |
Sep
(9) |
Oct
(14) |
Nov
(9) |
Dec
(5) |
2014 |
Jan
(13) |
Feb
(1) |
Mar
(6) |
Apr
(3) |
May
(5) |
Jun
(2) |
Jul
(20) |
Aug
(6) |
Sep
(26) |
Oct
(25) |
Nov
(20) |
Dec
(41) |
2015 |
Jan
(9) |
Feb
(35) |
Mar
(9) |
Apr
(28) |
May
(20) |
Jun
(3) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(4) |
Nov
|
Dec
(3) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(12) |
Jun
(35) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(7) |
2017 |
Jan
(28) |
Feb
(14) |
Mar
(4) |
Apr
(5) |
May
(4) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
(3) |
Nov
|
Dec
(8) |
2018 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(7) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(3) |
Nov
(7) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
(10) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(4) |
Apr
(21) |
May
(8) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
(10) |
Nov
|
Dec
|
2022 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2025 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
From: Christopher C. <chr...@gm...> - 2021-05-27 00:55:29
|
> I guess I'll try removing MacOS's pre-installed 8.5.18 and see if that helps. I don’t have any specific advice on what to try, however: • The patchlevel of macOS 10.15’s Tcl/Tk is 8.5.9. If you observe a patchlevel of 8.5.18 then that seems like a separate installation. • I would think SIP (System Integrity Protection) would try very hard to keep you from deleting the system Tcl/Tk, so I would not recommend trying to. Christopher A. Chavez |
From: Mansour M. <man...@gm...> - 2021-05-27 00:34:41
|
On Thu, May 20, 2021 at 11:21 AM Kevan Hashemi <ha...@br...> wrote: > > 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 What version of clang? Can you share the output of: export CC="$(xcrun --find clang)" $CC --version and also: xcodebuild -showsdks |
From: Kevan H. <ha...@br...> - 2021-05-26 15:49:31
|
Dear Nicolas, Thank you for your attention. > on macOS11.3 I successfully build Tcl/Tk (the core-8-branch for Tcl and > Trunk for Tk) It sounds like I will have to update to 11.3. > sudo make install I'm not trying to install TclTk in the operating system. I am building locally. The build fails at link time. Now, perhaps the build is mistakenly trying to link to installed versions of TclTk, which do indeed exist in MacOS 10.15, it has TclTk 8.5.18 loaded by default. When I build with "make embedded", the link fails just as for "make". I guess I'll try removing MacOS's pre-installed 8.5.18 and see if that helps. Best, kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://www.bndhep.net |
From: nicolas b. <sl1...@gm...> - 2021-05-20 16:20:31
|
Hi, on macOS11.3 I successfully build Tcl/Tk (the core-8-branch for Tcl and Trunk for Tk) so it's TclTk 8.7 my build command is (for both): *export* SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk *export* CC=/usr/bin/clang make -C macosx deploy CFLAGS="-O2 -mmacosx-version-min=10.15" sudo make install the tricky part is that you'll need to have tclsh8.7 in /usr/lib or /usr/local/lib and not tclsh8.6 nor tclsh8.5 so here, I'm looking for everything that is tclsh8.x, remove them, then build Tcl, then build Tk hope it helps. ++ nicolas Le jeu. 20 mai 2021 à 17:21, Kevan Hashemi <ha...@br...> a écrit : > 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 > > > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac > |
From: Kevan H. <ha...@br...> - 2021-05-20 15:20:58
|
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 |
From: Christopher C. <chr...@gm...> - 2021-05-04 22:50:21
|
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 |
From: Kevan H. <ha...@br...> - 2021-04-13 02:03:25
|
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 |
From: Marc C. <mar...@gm...> - 2021-04-12 18:44:04
|
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 > |
From: Kevan H. <ha...@br...> - 2021-04-12 18:24:04
|
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 |
From: Mansour M. <man...@gm...> - 2021-04-12 18:15:00
|
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. |
From: Marc C. <mar...@gm...> - 2021-04-12 17:53:49
|
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 |
From: Kevan H. <ha...@br...> - 2021-04-12 17:28:26
|
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 |
From: Marc C. <mar...@gm...> - 2021-04-12 16:31:18
|
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 > |
From: Kevan H. <ha...@br...> - 2021-04-12 03:30:59
|
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 |
From: Christopher C. <chr...@gm...> - 2021-04-11 03:40:46
|
> 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 |
From: Peter M. <pm...@ma...> - 2021-04-09 18:08:08
|
<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> <br> The useful "image create photo -format window -data <canvasID>" 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 & 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> |
From: Kevan H. <ha...@br...> - 2021-04-07 03:16:45
|
> 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 |
From: Jasper T. <ja...@si...> - 2021-04-06 13:56:47
|
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 |
From: Kevin W. <kw...@co...> - 2021-04-06 13:08:53
|
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 |
From: Jasper T. <ja...@si...> - 2021-04-06 12:28:33
|
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 |
From: Kevan H. <ha...@br...> - 2021-04-06 01:53:54
|
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 |
From: Mansour M. <man...@gm...> - 2021-04-04 14:01:23
|
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 |
From: Marc C. <mar...@gm...> - 2021-04-03 18:05:55
|
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 > |
From: Kevan H. <ha...@br...> - 2021-04-03 13:53:15
|
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 |
From: Mansour M. <man...@gm...> - 2021-04-02 16:12:47
|
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. |