#3048 OS X: libtk8.6.dylib install_name invalid path in unix build

[Ewen McNeill]

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.

[Kevin Walzer]

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.