#4293 error with [interp create] in embedded build on Mac

[Torsten Berg]

An embedded build of Tcl/Tk on the Mac (Intel) will fail on this command:

% interp create
Can't find a usable init.tcl in the following directories:
/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts /
Users/Torsten/Tcl/distrib/mac-builds/8.5.6/Applications/Utilities/

This is true for tclsh and wish in the Tcl/Tk versions 8.5.6 and the current development version of 8.6. It worked inall 8.5.x versions until and including 8.5.5

The embedded build was done using the procedure from the README:

export ver="8.5.6"
export dest="8.5.6"

make -C tcl${ver}/macosx/ embedded BUILD_DIR="/Users/Torsten/Tcl/
distrib/mac-builds/${dest}/" INSTALL_ROOT="/Users/Torsten/Tcl/distrib/
mac-builds/${dest}/"

make -C tk${ver}/macosx/ embedded BUILD_DIR="/Users/Torsten/Tcl/
distrib/mac-builds/${dest}/" INSTALL_ROOT="/Users/Torsten/Tcl/distrib/
mac-builds/${dest}/"

make -C tcl${ver}/macosx/ install-embedded INSTALL_ROOT="/Users/
Torsten/Tcl/distrib/mac-builds/${dest}/" BUILD_DIR="/Users/Torsten/Tcl/
distrib/mac-builds/${dest}/"

make -C tk${ver}/macosx/ install-embedded INSTALL_ROOT="/Users/Torsten/
Tcl/distrib/mac-builds/${dest}/" BUILD_DIR="/Users/Torsten/Tcl/distrib/
mac-builds/${dest}/"

[Don Porter]

Where is the init.tcl file for Tcl 8.5.6 installed?

Has the answer changed since release 8.5.5 ?

Has the set of directories on the search path changed
since release 8.5.5 ?

[Don Porter]

I'm guessing the 2008-12-07 commit to
tclMacOSXBundle.c is to blame. Nothing
in the ChangeLog about it das?

[Daniel A. Steffen]

that commit was supposed to be a pure leak fix, no functionality change:

http://fisheye.categorifiedcoder.info/changelog/Tcl/tcl/macosx?cs=MAIN:das:20081207162844

looking over it now to check for any new bugs...

[Daniel A. Steffen]

that change looks fine, only the CF leak is fixed and some extra NULLity checks added, nothing else changed, so I strongly doubt that this is the cause of the problem at hand...
no time to look into it further ATM unfortunately

[Benjamin Riefenstahl]

I have the same problem with my builds. I can't see an error in
our code.

Adding debug output shows that only the first call for the same
parameter succeeds, after that the routine does not find the
bundle any more (bundleRef is always NULL). Removing the
CFRelease(versionedBundleRef) fixes the problem.

At least in my environment (OS 10.4.11) I always get back the
same reference-counted object so at least here the memory leak
would not be a real problem. For now I just removed both the
CFRelease and the CFRetain in my sandbox.

[Daniel A. Steffen]

ok, that sounds familiar, I had a similar bug once when a CFBundle owned by CF was over-CFReleased, sounds like I'm doing this here, will look into it, thanks.

[Daniel A. Steffen]

this appears to be due to a bug in 10.4 CoreFoundation with CFBundle reference counting (CFRetain()ing and then CFRelease()ing a bundleRef obtained from CFBundleGetBundleWithIdentifier() results in that bundle being released and becoming unavailable for the lifetime of the process), the issue is not present on 10.5 or 10.6.

patch attached that works around this bug and should fix the problem.

[Daniel A. Steffen]

bug in 10.4 appears to extend to any CFRelease() of a CFBundle, once that has occurred, any subsequent attempt to recreate a bundle for that location fails. Adapted attached patch to bypass CFRelease() of bundle returned from CFBundleCreate() on 10.4 and earlier.

[Daniel A. Steffen]

patch against core-8-5-branch

[Daniel A. Steffen]

Committed to HEAD, core-8-5-branch and core-8-4-branch.