tk @8.6.0 +x11: bad install_name for libtk8.6.dylib

[ballapete (Peter "Pete" Dyballa)]

Upgrading MacPorts today brought Tcl/Tk 8.6.0. A few times port found that tk needed to be rebuilt, or whatever, because linking problems were found in that final stage of activating a port.

The last I encountered this effect was after ImageMagick's upgrade:

--->  Updating database of binaries
DEBUG: Ignoring loadcommand containing @executable_path in /Applications/MacPorts/Desktop Manager.app/Contents/MacOS/Desktop Manager
DEBUG: Ignoring loadcommand containing @executable_path in /Applications/MacPorts/Desktop Manager.app/Contents/PlugIns/DesktopPagerPlugin.bundle/Contents/MacOS/DesktopPagerPlugin
DEBUG: Ignoring loadcommand containing @executable_path in /Applications/MacPorts/Desktop Manager.app/Contents/PlugIns/OperationsMenu.bundle/Contents/MacOS/OperationsMenu
DEBUG: Ignoring loadcommand containing @executable_path in /Applications/MacPorts/Desktop Manager.app/Contents/PlugIns/StatusbarPagerPlugin.bundle/Contents/MacOS/StatusbarPagerPlugin
DEBUG: Ignoring loadcommand containing @executable_path in /Applications/MacPorts/Desktop Manager.app/Contents/Resources/PreferencePanes/HotKeysPreferences.bundle/Contents/MacOS/HotKeysPreferences
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/bin/quartz-wm
DEBUG: Missing architecture ppc64 in file /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
DEBUG: Missing architecture ppc64 in file outside prefix referenced from /opt/local/lib/libquartz-wm-ds.1.dylib
DEBUG: Missing architecture ppc64 in file /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
DEBUG: Missing architecture ppc64 in file outside prefix referenced from /opt/local/lib/libquartz-wm-ds.1.dylib
DEBUG: Missing architecture ppc64 in file /usr/lib/libXplugin.1.dylib
DEBUG: Missing architecture ppc64 in file outside prefix referenced from /opt/local/lib/libquartz-wm-ds.1.dylib
DEBUG: skipping x86_64 in /opt/local/lib/libquartz-wm-ds.1.dylib since this system can't run it anyway
DEBUG: Missing architecture i386 in file /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
DEBUG: Missing architecture i386 in file outside prefix referenced from /opt/local/lib/libquartz-wm-ds.1.dylib
DEBUG: Missing architecture i386 in file /usr/lib/libgcc_s.1.dylib
DEBUG: Missing architecture i386 in file outside prefix referenced from /opt/local/lib/libquartz-wm-ds.1.dylib
DEBUG: Missing architecture i386 in file /usr/lib/libSystem.B.dylib
DEBUG: Missing architecture i386 in file outside prefix referenced from /opt/local/lib/libquartz-wm-ds.1.dylib
DEBUG: Missing architecture i386 in file /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
DEBUG: Missing architecture i386 in file outside prefix referenced from /opt/local/lib/libquartz-wm-ds.1.dylib
DEBUG: Missing architecture i386 in file /usr/lib/libXplugin.1.dylib
DEBUG: Missing architecture i386 in file outside prefix referenced from /opt/local/lib/libquartz-wm-ds.1.dylib
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/bugpoint
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llc
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/lli
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-ar
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-as
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-bcanalyzer
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-diff
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-dis
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-extract
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-ld
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-link
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-mc
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-nm
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-objdump
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-prof
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvm-ranlib
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/llvmc
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/macho-dump
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/llvm-2.9/bin/opt
DEBUG: Missing architecture i386 in file /usr/lib/libSystem.B.dylib
DEBUG: Missing architecture i386 in file outside prefix referenced from /opt/local/share/cmake-2.8/Modules/CPack.OSXScriptLauncher.in
DEBUG: Missing architecture i386 in file /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
DEBUG: Missing architecture i386 in file outside prefix referenced from /opt/local/share/cmake-2.8/Modules/CPack.OSXScriptLauncher.in
--->  Scanning binaries for linking errors
Could not open /opt/local/lib:/opt/local/lib/libtk8.6.dylib: Error opening or reading file (referenced from /opt/local/bin/wish8.6)
DEBUG: Marking /opt/local/bin/wish8.6 as broken

--->  Found 1 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
DEBUG: Broken: tk
DEBUG: Processing port tk @0:8.6.0_0  
--->  Rebuilding in order
     tk @8.6.0 

The build of wish really is a bit strange, as otool tells as well:

pete 240 /\ otool -L  /opt/local/bin/wish8.6
/opt/local/bin/wish8.6:
        /opt/local/lib/libfontconfig.1.dylib (compatibility version 8.0.0, current version 8.2.0)
        /opt/local/lib:/opt/local/lib/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
        /opt/local/lib/libtcl8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 368.35.0)
        /opt/local/lib/libXft.2.dylib (compatibility version 6.0.0, current version 6.1.0)
        /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
        /opt/local/lib/libXss.1.dylib (compatibility version 2.0.0, current version 2.0.0)
        /opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

The build tree was cleaned and no main.log file was created and left, so I might need to retry the build of Tk to find the cause for "opt/local/lib:/opt/local/lib/libtk8.6.dylib" in some Makefile, presumingly?

[nonstop.server@…]

Cc Me!

[ewen-naos-nz (Ewen McNeill)]

Cc Me!

[ewen-naos-nz (Ewen McNeill)]

Also affects Snow Leopard (10.6.8) on Intel:

ewen@bethel:~$ ewencbb
dyld: Library not loaded: /opt/local/lib:/opt/local/lib/libtk8.6.dylib
  Referenced from: /opt/local/bin/wish
  Reason: image not found
[...]
ewen@bethel:~$ port installed tk
The following ports are currently installed:
  tk @8.5.13_0+quartz
  tk @8.5.13_0+x11
  tk @8.6.0_0+x11 (active)
ewen@bethel:~$ 

with similar three attempts at rebuilding, and advice to file this build debug:

ewen@bethel:~$ egrep -v '/opt/local/lib/wine|/opt/local/libexec/llvm-' /tmp/tk-failed-after-upgrade.txt 
Script started on Thu Dec 27 09:04:05 2012
ewen@bethel:~$ sudo port -d -y rev-upgrade
Password:
DEBUG: skipping ppc64 in /opt/local/lib/libquartz-wm-ds.1.dylib since this system can't run it anyway
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/bin/wineserver
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/bin/wmc
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/bin/wrc
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/wine/wine
DEBUG: Ignoring loadcommand containing @executable_path in /opt/local/libexec/ld64/ld
--->  Scanning binaries for linking errors
Could not open /opt/local/lib:/opt/local/lib/libtk8.6.dylib: Error opening or reading file (referenced from /opt/local/bin/wish8.6)
DEBUG: Marking /opt/local/bin/wish8.6 as broken

--->  Found 1 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
DEBUG: Broken: tk
DEBUG: Processing port tk @0:8.6.0_0 +x11 
--->  Rebuilding in order
     tk @8.6.0 +x11
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: tk 8.6.0_0 exists in the ports tree
DEBUG: tk 8.6.0_0 +x11 is the latest installed
DEBUG: tk 8.6.0_0 +x11 is active
DEBUG: Merging existing variants '+x11' into variants
DEBUG: new fully merged portvariants: x11 +
DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/x11/tk
DEBUG: OS darwin/10.8.0 (Mac OS X 10.6) arch i386
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: adding the default universal variant
DEBUG: Executing variant x11 provides x11
DEBUG: rev-upgrade override ... upgrading!
DEBUG: Not following dependencies
Skipping deactivate tk @8.6.0_0+x11 (dry run)
Skipping activate tk @8.6.0_0+x11 (dry run)
DEBUG: Rebuilding port tk finished with status 0
Warning: If this was no dry run, rev-upgrade would now run the checks again to find unresolved and newly created problems
ewen@bethel:~$ exit

Since the affected binary (wish8.6) is provided by the affected port:

ewen@bethel:~$ port provides /opt/local/bin/wish8.6
/opt/local/bin/wish8.6 is provided by: tk
ewen@bethel:~$ 

rebuilding the port doesn't seem likely to help. It seems likely to be a path override incorrectly specified somewhere. The implied dylib file does exist:

ewen@bethel:~$ ls -l /opt/local/lib/libtk8.6.dylib
-r-xr-xr-x  1 root  admin  1353936 27 Dec 09:00 /opt/local/lib/libtk8.6.dylib
ewen@bethel:~$ 

so the only problem seems to be the embedded path to it.

Ewen

[ewen-naos-nz (Ewen McNeill)]

For reference, embedded linking/paths in the 8.6.0 /opt/local/bin/wish8.6:

ewen@bethel:~$ otool -L /opt/local/bin/wish8.6 
/opt/local/bin/wish8.6:
	/opt/local/lib/libfontconfig.1.dylib (compatibility version 8.0.0, current version 8.2.0)
	/opt/local/lib:/opt/local/lib/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
	/opt/local/lib/libtcl8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.44.0)
	/opt/local/lib/libXft.2.dylib (compatibility version 6.0.0, current version 6.1.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libXss.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
ewen@bethel:~$ 

compared with what was in 8.5.13 (previous package I had installed), activate reactivating the older build:

ewen@bethel:~$ otool -L /opt/local/bin/wish8.5 
/opt/local/bin/wish8.5:
	/opt/local/lib/libfontconfig.1.dylib (compatibility version 8.0.0, current version 8.2.0)
	/opt/local/lib/libtk8.5.dylib (compatibility version 8.5.0, current version 8.5.13)
	/opt/local/lib/libtcl8.5.dylib (compatibility version 8.5.0, current version 8.5.13)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.44.0)
	/opt/local/lib/libXft.2.dylib (compatibility version 6.0.0, current version 6.1.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libXss.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
ewen@bethel:~$ 

Note the "/opt/local/lib:/opt/local/lib" prefix to the libtk8.6.dylib file, which doesn't appear like that in the 8.5 file.

It's not obvious to me what has changed in the Portfile to provoke that change in embedded path.

Ewen

[ewen-naos-nz (Ewen McNeill)]

With some searching I found "install_name_tool" (from ​a Stack Exchange question about OSX library linking with full paths), which can be used to change the embedded path to a dylib within an executable, viz:

sudo install_name_tool -change "/opt/local/lib:/opt/local/lib/libtk8.6.dylib" "/opt/local/lib/libtk8.6.dylib" /opt/local/bin/wish8.6

and having fixed the libtk8.6.dylib embedded path to be the obvious one (with the above command), it will then run, and the port "rev-upgrade" check doesn't find any issues. So that embedded path seems to be the only problem (can someone change the ticket subject?)

That "install_name_tool" manual change should at least provide a temporary work around (ie, until the next port build of tk) for anyone who has installed the 8.6.0 version and doesn't want to revert to the 8.5.13 (or similar) version.

For reference, full approach:

ewen@bethel:~$ sudo port activate tk @8.6.0_0+x11
--->  Computing dependencies for tk
--->  Deactivating tk @8.5.13_0+x11
--->  Cleaning tk
--->  Activating tk @8.6.0_0+x11
--->  Cleaning tk
ewen@bethel:~$ sudo cp -p /opt/local/bin/wish8.6 /opt/local/bin/wish8.6-bkup-2012-12-27
ewen@bethel:~$ sudo install_name_tool -change "/opt/local/lib:/opt/local/lib/libtk8.6.dylib" "/opt/local/lib/libtk8.6.dylib" /opt/local/bin/wish8.6
ewen@bethel:~$ otool -L /opt/local/bin/wish8.6
/opt/local/bin/wish8.6:
	/opt/local/lib/libfontconfig.1.dylib (compatibility version 8.0.0, current version 8.2.0)
	/opt/local/lib/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
	/opt/local/lib/libtcl8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.44.0)
	/opt/local/lib/libXft.2.dylib (compatibility version 6.0.0, current version 6.1.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libXss.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
ewen@bethel:~$ sudo port -d -y rev-upgrade 2>&1 | grep -v DEBUG
--->  Scanning binaries for linking errors
--->  No broken files found.
ewen@bethel:~$ 

Ewen

[ewen-naos-nz (Ewen McNeill)]

FTR, from a ​hint in this blog post I was able to confirm that the "install name" embedded in the libtk8.6.dylib file contains the incorrect path, and it appears that then gets copied into the binary at link time. Hopefully that provides a hint for where to start looking for the underlying build problem.

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:~$ 

(This also means that if you have anything else which links against libtk, then you'll either (a) need to fix the install name in libtk8.6.dylib before building the other things, or (b) go around and fixup each executable individually. In my case I only use TCL/TK, via wish, for one programme, so fixing wish8.6 was sufficient.)

Ewen

[ryandesign (Ryan Carsten Schmidt)]

Yes, the install_name is clearly wrong, but why? I do not see the problem on Mountain Lion x86_64 nor on Leopard i386 so please attach a main.log of the failed build. Unless you've set "keeplogs yes" in /opt/local/etc/macports/macports.conf, MacPorts will have deleted the log, since the build was successful. So either set "keeplogs yes" and rebuild tk ("sudo port -n upgrade --force tk"), or else use the -k flag to tell MacPorts to keep the log (and work directory) for this build only ("sudo port -kn upgrade --force tk"). Then attach the main.log to this ticket.

[ryandesign (Ryan Carsten Schmidt)]

The location of the logfile is printed by the command:

port logfile tk

[pengyu.ut@…]

Cc Me!

[pengyu.ut@…]

Replying to ryandesign@…:

The location of the logfile is printed by the command:

port logfile tk

I don't find it.

~$ port logfile tk
Error: Log file not found for port in /opt/local/var/macports/sources/rsync.macports.org/release/ports/x11/tk

[ryandesign (Ryan Carsten Schmidt)]

Read comment:7.

[ewen-naos-nz (Ewen McNeill)]

Snow Leopard (10.6.8) build log attached, from forced rebuild as suggested. Appears to reproduce the problem. Terminal output from build below, for reference.

ewen@bethel:~$ sudo port -kn upgrade --force tk
Password:
--->  Computing dependencies for tk
--->  Deactivating tk @8.6.0_0+x11
--->  Cleaning tk
--->  Uninstalling tk @8.6.0_0+x11
--->  Cleaning tk
--->  Computing dependencies for tk
--->  Fetching archive for tk
--->  Attempting to fetch tk-8.6.0_0+x11.darwin_10.x86_64.tbz2 from http://packages.macports.org/tk
--->  Attempting to fetch tk-8.6.0_0+x11.darwin_10.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/tk
--->  Attempting to fetch tk-8.6.0_0+x11.darwin_10.x86_64.tbz2 from http://lil.fr.packages.macports.org/tk
--->  Fetching distfiles for tk
--->  Verifying checksum(s) for tk
--->  Extracting tk
--->  Configuring tk
--->  Building tk
--->  Staging tk into destroot
--->  Installing tk @8.6.0_0+x11
--->  Activating tk @8.6.0_0+x11
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 100.0%
--->  Found 1 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
     tk @8.6.0 +x11
--->  Computing dependencies for tk
--->  Scanning binaries for linking errors: 100.0%
--->  Found 1 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
     tk @8.6.0 +x11
--->  Computing dependencies for tk
--->  Deactivating tk @8.6.0_0+x11
--->  Cleaning tk
--->  Uninstalling tk @8.6.0_0+x11
--->  Cleaning tk
--->  Computing dependencies for tk
--->  Installing tk @8.6.0_0+x11
--->  Activating tk @8.6.0_0+x11
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 100.0%
--->  Found 1 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
     tk @8.6.0 +x11
--->  Computing dependencies for tk
--->  Deactivating tk @8.6.0_0+x11
--->  Cleaning tk
--->  Uninstalling tk @8.6.0_0+x11
--->  Cleaning tk
--->  Computing dependencies for tk
--->  Installing tk @8.6.0_0+x11
--->  Activating tk @8.6.0_0+x11
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 100.0%
--->  Found 1 broken file(s), matching files to ports
Error: Port tk is still broken after rebuiling it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.
Port tk still broken after rebuilding 3 time(s)
[.... random "port" stack trace stuff removed, since it seems irrelevant ....]
ewen@bethel:~$ port logfile tk
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_tk/tk/main.log
ewen@bethel:~$ otool -L /opt/local/bin/wish8.6
/opt/local/bin/wish8.6:
	/opt/local/lib/libfontconfig.1.dylib (compatibility version 8.0.0, current version 8.2.0)
	/opt/local/lib:/opt/local/lib/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
	/opt/local/lib/libtcl8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.44.0)
	/opt/local/lib/libXft.2.dylib (compatibility version 6.0.0, current version 6.1.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libXss.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
ewen@bethel:~$ 

I've not looked at the build log yet. I'll have a glance through and add another comment if anything jumps out at me as a possible cause.

Ewen

[ryandesign (Ryan Carsten Schmidt)]

All of the relevant phases (configure, build and possibly destroot) are not in your log (it just says "Skipping completed" for those phases). Possibly this is because of how rev-upgrade works; I forgot that runs by default; I have it turned off in my MacPorts installation. Please try again and disable rev-upgrade for this build:

sudo port clean tk
sudo port -kn upgrade --force --no-rev-upgrade tk

[ewen-naos-nz (Ewen McNeill)]

tk 8.6.0 build on Snow Leopard (with --no-rev-upgrade), resulting in strange install_name on libtk8.6.dylib

[ewen-naos-nz (Ewen McNeill)]

Yes, I noticed that when I started looking at the log file and was hunting for a way to disable rev-upgrade as your email came in (I think rev-upgrade is what is shortcutting the rebuild due to there being an archived file created, so that's what is ending up in the archive file). It seems the build log I just attached is even shorter, despite it having compile stuff in it when I checked earlier; I'll try again in a minute.

Ewen

[ryandesign (Ryan Carsten Schmidt)]

Hmm, yes. Perhaps try:

sudo port clean tk
sudo port -f uninstall tk
sudo port -k install --no-rev-upgrade tk

[ewen-naos-nz (Ewen McNeill)]

Possible discovery, while trying to get a full clean build log with:

sudo port clean tk
sudo port -skn upgrade --force --no-rev-upgrade tk

which resulted in a clean build with a full log, but installed the Quartz version (I had previously installed the x11 flavour). So my hunch is that the Quartz build works, and the x11 flavour doesn't, for some reason. I'll attach the Quartz build log for reference, and then see if I can get a full rebuild log for the x11 flavour. (I think I managed to switch back to the default, Quartz, flavour by interrupting one of the rebuilds after it'd deactivated the previous install but before it finished building/installing the new one; that probably doesn't count as a bug.)

ewen@bethel:~$ port installed tk
The following ports are currently installed:
  tk @8.5.13_0+quartz
  tk @8.5.13_0+x11
  tk @8.6.0_0+quartz (active)
ewen@bethel:~$ otool -L /opt/local/bin/wish8.6 | grep libtk
	/opt/local/lib/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
ewen@bethel:~$ otool -D /opt/local/lib/libtk8.6.dylib 
/opt/local/lib/libtk8.6.dylib:
/opt/local/lib/libtk8.6.dylib
ewen@bethel:~$ 

Ewen

[ryandesign (Ryan Carsten Schmidt)]

Replying to macports@…:

So my hunch is that the Quartz build works, and the x11 flavour doesn't, for some reason.

Confirmed on Mountain Lion.

[ewen-naos-nz (Ewen McNeill)]

FTR, the way to get a full build log, one-shot, is:

sudo port clean tk
sudo port -skn upgrade --force --no-rev-upgrade tk -quartz +x11

with an already activated port. It appears if you have uninstalled/deactivated, then you'll just get the install phase, as it'll build it and then recycle around to check if it should activate it -- and then it'll overwrite the log with the activation only one.

This is the command putting the install name in:

:info:build /usr/bin/gcc-4.2 -dynamiclib -Os -O2 -arch x86_64 -pipe -fvisibility=hidden  -arch x86_64 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_tk/tk/work/tcl8.6.0/generic   -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_tk/tk/work/tk8.6.0/unix -L/opt/local/lib -lfontconfig -arch x86_64 -headerpad_max_install_names -Wl,-search_paths_first  -Wl,-single_module -o libtk8.6.dylib tk3d.o tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkBusy.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o tkConsole.o tkCursor.o tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o tkPlace.o tkSelect.o tkStyle.o tkUndo.o tkUtil.o tkVisual.o tkWindow.o tkButton.o tkEntry.o tkFrame.o tkListbox.o tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o tkPanedWindow.o tkScale.o tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o tkImgGIF.o tkImgPNG.o tkImgPPM.o tkImgPhoto.o tkImgPhInstance.o tkText.o tkTextBTree.o tkTextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o tkTextWind.o tkStubInit.o ttkBlink.o ttkButton.o ttkCache.o ttkClamTheme.o ttkClassicTheme.o ttkDefaultTheme.o ttkElements.o ttkEntry.o ttkFrame.o ttkImage.o ttkInit.o ttkLabel.o ttkLayout.o ttkManager.o ttkNotebook.o ttkPanedwindow.o ttkProgress.o ttkScale.o ttkScrollbar.o ttkScroll.o ttkSeparator.o ttkSquare.o ttkState.o ttkTagSet.o ttkTheme.o ttkTrace.o ttkTrack.o ttkTreeview.o ttkWidget.o ttkStubInit.o tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o  tkUnixRFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o tkUnixXId.o   -lpthread -framework CoreFoundation -L/opt/local/lib -lXft   -L/opt/local/lib -lX11 -Wl,-weak-lXss -lXext  -lz  -lpthread -framework CoreFoundation  -L/opt/local/lib -ltclstub8.6 -compatibility_version 8.6 -current_version 8.6.0 -install_name "/opt/local/lib:/opt/local/lib/libtk8.6.dylib" -sectcreate __TEXT __info_plist Tk-Info.plist 

which clearly has the wrong string for the install_name. That's the only place in the log that "/opt/local /lib:" appears, so it must be assembling it somewhere that doesn't turn up in the log; I'll see if I can look at the generated makefile in a second.

FWIW, I found that I had to explicitly say "-quartz +x11" on backing out of having the quartz flavour (even after uninstalling the active quartz flavour version), otherwise I got a conflict:

ewen@bethel:~$ sudo port -skn upgrade --force --no-rev-upgrade tk +x11
Error: tk: Variant quartz conflicts with x11
Error: Unable to open port: Error evaluating variants
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
ewen@bethel:~$

IIRC when I did this on 8.5.13, I just said "+x11" and the -quartz was implied. Maybe I'm misremembering, or maybe +x11 is no longer implying -quartz.

Ewen

[ryandesign (Ryan Carsten Schmidt)]

In unix/configure.in we have:

LIB_RUNTIME_DIR='$(libdir)'

And then later:

if test "x${x_libraries}" != "x"; then
  if test "x${x_libraries}" != "xNONE"; then
    LIB_RUNTIME_DIR="${LIB_RUNTIME_DIR}:${x_libraries}"
  fi
fi
if test "${TCL_LD_SEARCH_FLAGS}" = '-L${LIB_RUNTIME_DIR}'; then
    LIB_RUNTIME_DIR=`echo ${LIB_RUNTIME_DIR} |sed -e 's/:/ -L/g'`
fi

In unix/Makefile.in we have:

TK_SHLIB_LD_EXTRAS	= @TK_SHLIB_LD_EXTRAS@

After configure runs, this gets expanded in unix/Makefile to:

TK_SHLIB_LD_EXTRAS	= -compatibility_version 8.6 -current_version 8.6.0 -install_name "${DYLIB_INSTALL_DIR}/${TK_LIB_FILE}" -sectcreate __TEXT __info_plist Tk-Info.plist

And then later in that file we have:

DYLIB_INSTALL_DIR	= ${LIB_RUNTIME_DIR}

This certainly seems to be a bug in the tk build system. It should be ​reported to the developers of tk.

---

For our purposes in MacPorts, since we know that libdir and x_libraries will always be the same thing, we could just remove this block:

if test "x${x_libraries}" != "x"; then
  if test "x${x_libraries}" != "xNONE"; then
    LIB_RUNTIME_DIR="${LIB_RUNTIME_DIR}:${x_libraries}"
  fi
fi

[ewen-naos-nz (Ewen McNeill)]

Looks like we've come to the same conclusion on the root cause (I was writing it up for the ticket when your email came in). I'd suggest the most expedient thing to patch would be DYLIB_INSTALL_DIR, in Makefile.in, since it's closer to where the install_name is set and _only_ used for that install_name setting. Macports could probably perfectly safely set that to ${libdir}, and all would be well. That might even be a clean upstreamable fix, since DYLIB_INSTALL_DIR appears to only be for Darwin/OS X, both of which could have this problem and for which ${libdir} should eventually be correct.

Ewen

[ryandesign (Ryan Carsten Schmidt)]

Replying to macports@…:

I'd suggest the most expedient thing to patch would be DYLIB_INSTALL_DIR, in Makefile.in, since it's closer to where the install_name is set and _only_ used for that install_name setting. Macports could probably perfectly safely set that to ${libdir}, and all would be well. That might even be a clean upstreamable fix, since DYLIB_INSTALL_DIR appears to only be for Darwin/OS X, both of which could have this problem and for which ${libdir} should eventually be correct.

I like that a lot. Very simple. r100816.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign@…:

Replying to macports@…:

I'd suggest the most expedient thing to patch would be DYLIB_INSTALL_DIR, in Makefile.in, since it's closer to where the install_name is set and _only_ used for that install_name setting. Macports could probably perfectly safely set that to ${libdir}, and all would be well. That might even be a clean upstreamable fix, since DYLIB_INSTALL_DIR appears to only be for Darwin/OS X, both of which could have this problem and for which ${libdir} should eventually be correct.

I like that a lot. Very simple. r100816.

On Tiger the upgrade to tk 6.8.0_1 brought success: normalisation, working wish!

[pengyu.ut@…]

Log of port logfile tk

[ewen-naos-nz (Ewen McNeill)]

Replying to ryandesign@…:

I like that a lot. Very simple. r100816.

Works on Snow Leopard (10.6.8). Thanks for the quick turn around of a committed fix.

ewen@bethel:~$ port installed tk
The following ports are currently installed:
  tk @8.5.13_0+quartz
  tk @8.5.13_0+x11
  tk @8.6.0_0+x11
  tk @8.6.0_1+x11 (active)
ewen@bethel:~$ otool -D /opt/local/lib/libtk8.6.dylib 
/opt/local/lib/libtk8.6.dylib:
/opt/local/lib/libtk8.6.dylib
ewen@bethel:~$ 

Ewen

[ewen-naos-nz (Ewen McNeill)]

For completeness, reported to tk bug tracker as ​tk bug 3598664, referencing this ticket. I've suggested they use the same fix that we came up with (set DYLIB_INSTALL_DIR from ${libdir}), given various people have confirmed it works at least within MacPorts. (Also FWIW I've ​written up my dylib issue investigation notes as a blog post for future reference.)

Ewen