|
|
(long discussion of Tk_PhotoExpand incompatibility between
8.3 and 8.4 deleted).
The tables you have shown are what I expect to see.
In order to use an extension across releases with 100% confidence,
you need to:
- Always set USE_TCL_STUBS. Calling Tcl_InitStubs
in code that isn't compiled to use Stubs should
be harmless but of course does nothing to adapt
the ABI.
- compile using the header files of the earliest release
that you plan to support. The header files of newer
releases may have hidden dependencies on those releases,
even if you are not using the specific functionality
of the newer release.
- link using the Stub libraries of the earliest release
that you plan to support. The Stub libraries must match
the headers.
- never call Tcl_InitStubs with any release other than
the one whose headers you used. In fact, TCL_VERSION
is almost always the right thing to pass to Tcl_InitStubs.
This means that your code will be constrained to use
the API of the earliest version that you plan to support.
Even when loading into 8.5, you'll continue to use the
old interface for Tk_PhotoExpand, and not have the benefit
of its new features.
This combination gives your table 1:
1 - ...InitStubs(..., 0) + with USE_TCL/TK_STUBS
------------------------------------------------
build version
8.3 8.4 8.5
8.3 ok CRASH1 CRASH1
load
version 8.4 ok ok err
8.5 ok ok ok
Since you intend to support 8.3, you build against 8.3, and
it loads successfully against everything newer. This gives
you the combination that builds a single module that all
your customers can run.
So you certainly have one recipe to avoid the CRASHes -
Don't Do That.
(Your tables 2 and 3 already fall under Don't Do That -
why would you initialize a Stubs interface that you don't
intend to use?)
That leaves us with only the problem that you get a crash
rather than an informative error message when your customer
tries to load your extension into a release that you do
not support. This appears to be a problem only with 8.3,
which *we* no longer support, so you're unlikely to get
much help with fixing it at a fundamental level. But if you
use the [package] mechanism rather than a direct [load] -
a good idea in any case - then you can simply stick a
[package require Tk 8.4] inside your [package ifneeded]
script in pkgIndex.tcl, and the script will error out
on the missing dependency before ever attempting to load
the library. That is, instead of:
package ifneeded Mypackage 1.0 {
load [file join $dir mypackage10.dll]
}
make it:
# A line like the following makes the package invisible
# in an unsupported interpreter
if {![package vsatisfies [package provide Tcl] 8.4]} return
package ifneeded Mypackage 1.0 {
# A line like the following requires a particular
# dependency prior to loading the library
package require Tk 8.4; # needs the new Tk_PhotoExpand
load [file join $dir mypackage10.dll]
}
--
73 de ke9tv/2, Kevin
|
|