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

#2965 unixInit-2.8 fails

obsolete: 8.4.8
closed-fixed
5
2004-11-19
2004-11-17
Don Porter
No

Test unixInit-2.8 is now failing
on both active branches in
the macosx build. I believe
this is a recent regression.
Any clue what we broke?

Discussion

  • Don Porter
    Don Porter
    2004-11-17

    Logged In: YES
    user_id=80530

    Somehow the bogus value
    @TCL_IN_FRAMEWORK@
    is getting exposed to the test.

    Is there some way we can
    prevent that value from leaking
    into the $tcl_libPath value or
    the [tcl::pkgconfig get scriptdir,runtime]
    value?

    If not, we need to constrain this test
    not to run in the Mac framework configuration.

    Still not clear to me why this just
    started failing recently.

     
  • Don Porter
    Don Porter
    2004-11-17

    Logged In: YES
    user_id=80530

    It appears that macosx Makefile
    sets TCL_LIBRARY = @TCL_IN_FRAMEWORK@
    and then the routine MacOSXGetLibraryPath
    checks for that value as a signal that it
    should call Tcl_MacOSXOpenVersionedBundleResources().

    The MOGLP () routine definition, is already
    protected by a HAVE_CFBUNDLE to control
    at compile time whether it is called. Isn't that
    enough? What is the use case where an
    additional compile-time signal is needed?

     
  • Don Porter
    Don Porter
    2004-11-18

    Logged In: YES
    user_id=80530

    Here's a patch that corrects the
    problem for me. Can someone
    more knowledgable about "frameworks"
    either approve it, or explain in short
    words and big cartoon figures what
    is wrong with it? Thanks.

     
  • Don Porter
    Don Porter
    2004-11-18

     
    Attachments
  • Don Porter
    Don Porter
    2004-11-18

    • priority: 9 --> 5
     
  • Don Porter
    Don Porter
    2004-11-18

    Logged In: YES
    user_id=80530

    I just test Tcl 8.4.7 and my earlier
    claims that this is a new failure were
    mistaken.

    While I'd still like to sort this out,
    I'm dropping priority; I no longer
    consider this an 8.4.8 release blocker.

     
  • Logged In: YES
    user_id=90580

    as mentioned, this is not a new test failure, we've discussed it before, bug
    931061, this bug is a duplicate.

    I'm suspicious of your patch because it does not deal with the fact that tcl
    might not have been built as a framework (HAVE_CFBUNDLE has nothing
    to do with that, it's only about the availibitly of the bundle API).
    If we called Tcl_MacOSXOpenVersionedBundleResources
    unconditionally, this might then find the tcl library files in an unrelated
    Tcl.framework that we are not actually linked against.

    The current technique is a kludge but the only side-effect I've seen so far
    is unixInit-2.8 failing, so it hadn't been high on my list of things to
    improve.
    What was needed is a better way for tcl to determine that it
    has been built as a framework, the attached (and committed) patch uses
    an extra configure #define TCL_FRAMEWORK set when configured
    with --enable-framework, and removes the overloading of TCL_LIBRARY.

     
    • status: open --> closed-fixed
     
  •  
    Attachments