Tk Source Code

When using the "unix" build (ie, X11, rather than Quartz) on OS X, at least when building with MacPorts, the configure script and Makefile supplied with 8.6.0 results in stamping an invalid search-path like path name for libtk8.6.dylib into the dynamic library as the "install_name" (ie, canonical pathname for the library), which then gets copied into the wish8.6 executable as the location from which to load the library.  Since the search-path style string is not a valid file pathname, the library can't be found and hence the wish8.6 executable cannot be loaded.  This behaviour seems to be new since 8.5.13, although the underlying cause may have been there for quite some time.

Symptoms:

When trying to run something that uses wish:

dyld: Library not loaded: /opt/local/lib:/opt/local/lib/libtk8.6.dylib
  Referenced from: /opt/local/bin/wish
  Reason: image not found

and inside the files:

ewen@bethel:~$ otool -D /opt/local/lib/libtk8.6.dylib
/opt/local/lib/libtk8.6.dylib:
/opt/local/lib:/opt/local/lib/libtk8.6.dylib
ewen@bethel:~$

ewen@bethel:~$ otool -L /opt/local/bin/wish8.6 | grep libtk
        /opt/local/lib:/opt/local/lib/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
ewen@bethel:~$

Based on the MacPorts trouble ticket investigation:

https://trac.macports.org/ticket/37395

the fundamental problem is that DYLIB_INSTALL_DIR is used directly as part of the "install_name" for the OS X dylib, but the supplied Makefile.in copies that directly from LIB_RUNTIME_DIR which the configure script (now?) assembles into a library search path.  (It seems to me that LIB_RUNTIME_DIR is misnamed, if it is being treated as a RPATH-style search path.)  The most immediate trigger seems to be adding the X11 library location to the existing LIB_RUNTIME_DIR path (containing ${libdir}), but I'm not sure if that's new in the tk configure script or just being triggered now.

The easiest work around, proven to work in MacPorts, is to set DYLIB_INSTALL_DIR from ${libdir} instead of from ${LIB_RUNTIME_DIR}:

-DYLIB_INSTALL_DIR       = ${LIB_RUNTIME_DIR} 
+DYLIB_INSTALL_DIR       = $(libdir) 

(see patch being carried by Macports: https://trac.macports.org/browser/trunk/dports/x11/tk/files/patch-unix-Makefile.in.diff?rev=100816)

Ewen

PS: I'm not sure if this is "Mac OS X Build" or the "Unix Build", since it is the legacy unix/X11 handling on OS X which has the problem not the new Quartz handling.  But OS X is the only platform I'm aware of that uses this "install_name" canonical path stamping approach, so I went with that.  Feel free to change as appropriate.

This just got fixed,

See: https://core.tcl-lang.org/tk/info/8b679f597b1d17ad
(which was a duplicate).

I'm also experiencing this bug with the Spack package manager, see https://github.com/spack/spack/issues/23780. This is on macOS 10.15.7 with Apple Clang 12.0.0.

Whoops.  Correcting the configure aruments:

../unix/configure --prefix=$HOME/t/localD --with-tcl=$HOME/t/localD/lib --with-tk=$HOME/t/localD/lib --enable-aqua --enable-corefoundation

And this builds a wish executable with the correct path.
Trying to build an X11 executable:

../unix/configure --prefix=$HOME/t/localD --with-tcl=$HOME/t/localD/lib --with-tk=$HOME/t/localD/lib --enable-corefoundation

And the wish executable has a bad path:
   /Volumes/Users/bll/t/localD/lib:/usr/X11R6/lib/libtk8.6.dylib

Using:

../unix/configure --prefix=$HOME/t/localD --with-tcl=$HOME/t/localD/lib --with-tk=$HOME/t/localD/lib --with-aqua --with-corefoundation
make -f Makefile -j 4 install

Library path in wish8.6 ends up incorrectly set to: 
   /Volumes/Users/bll/t/localD/lib:/usr/X11R6/lib/libtk8.6.dylib

I am reassigning this to Jan, since he usually fixes these issues.

As far as I can tell, there is currently no method to create a working MacOS executable out of the box.

MacPorts is still applying this change to both the +x11 and +quartz variants; there is nothing in the port that disables it for either variant. I've regularly used both variants so I would say the change is safe. Can it finally be incorporated upstream?

I've confirmed the issue with an X11/Unix build of Tk 8.6, but I'm concerned that your proposed change would break the native build--that's what that line in Makefile.in is for AFAIK. Can you test your patch against the "Quartz" variant of Tk in MacPorts to ensure no breakage? If so I'll commit it, otherwise I will leave it as is.