Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

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

obsolete: 8.5.6
closed-fixed
9
2009-10-05
2009-02-05
Torsten Berg
No

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}/"

Discussion

1 2 > >> (Page 1 of 2)
  • Don Porter
    Don Porter
    2009-02-05

    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
    Don Porter
    2009-02-05

    • assigned_to: dgp --> das
     
  • Don Porter
    Don Porter
    2009-02-05

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

     
  • 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

     
  • 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.

     
  • 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.

     
    • priority: 5 --> 8
     
  • 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.

     
    • priority: 8 --> 9
     
1 2 > >> (Page 1 of 2)