Tcl Source Code

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?

File Added - 109317: 1068088-core-8-4-branch.diff

File Added - 109316: 1068088-HEAD.diff

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.

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.

File Added - 109177: 1068088.patch

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.

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?

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.