Darwin has two formats for dynamically loadable binaries: shared
libraries aka .dylibs (MH_DYLIB) and .bundles (MH_BUNDLE). Currently
tclLoadDyld.c only supports [load]ing .dylibs, the following patch adds
[load]ing of .bundles:
this modifies TclpDlopen() to attempt loading a file as a .bundle via
NSCreateObjectFileImageFromFile() when NSAddImage() has failed to lad
it as a .dylib.
The main user-visible advantage of [load]ing .bundles is that such
extensions can be [unload]ed, whereas dyld does not actually support
unloading of .dylibs even if [unload] appears to succeed (the patch
also removes attempting to unload .dylibs).
MH_BUNDLE is also the binary format used by loadable extensions for
other languages on the platform (perl, python, apache,...), which
brings us more in line which their usage (the original tcl port to
Darwin was using .bundles as well but we switched to .dylibs at some
point to make porting of extension buildsystems easier).
Indeed, the disadvantage of .bundles is that they need to be linked
differently than shared libraries, which introduces a platform
discrepancy in buildsystems (e.g. TEA3 does not support linking as
.bundle at present), and that unlike shared libs, .bundles cannot be
linked against from other binaries (which is a problem for Tk and for
extensions like expect that have dependent binaries).
Another advantage of .bundles is that OSX 10.3 allows MH_BUNDLE
binaries to be loaded from memory; this allows direct [load]ing of
.bundles from VFSs such as starkits, instead of having to first copy
them out of VFS to a temporary location as is done in tcl currently.
In addition to the changes above (which are independent of this), the
patch adds that capability to TclLoadFile() in tclIOUtil.c (when
TCL_LOAD_FROM_MEMORY is #defined), via new platform specific procs
TclpLoadMemoryGetBuffer() and TclpLoadMemory(). These are only
implemented in tclLoadDyld.c at present, but other platforms may have
the capability to load binary code from memory as well?
I would be grateful for review and comments of these changes, esp
concerning availability of loading code from memory on other platforms.
Given that this change only affects internal APIs I don't believe it
needs to be TIPd but the requirements of other platforms should be
considered in the design...
Another question is if some or all of this should be backported to
As a separate issue, another small change in the patch to tcl.m4 shows
how to use the new MODULE_SCOPE macro on Darwin to prevent tcl internal
symbols to be exported from the tcl shared library. Unfortunately, as
shown in tclLoadDyld.c, for this to work on Darwin, MODULE_SCOPE needs
to be added to _both_ the declaration and the implementation of an
Does anybody know if the presence of MODULE_SCOPE on function
implementations will cause problems on other platforms? (if undefined,
MODULE_SCOPE is #defined to be 'extern' in tclInt.h) If yes, we may
need to introduce a separate macro for module scope implementations.
** Daniel A. Steffen ** "And now for something completely
** Dept. of Mathematics ** different" Monty Python
** Macquarie University ** <mailto:steffen@...>
** NSW 2109 Australia ** <http://www.maths.mq.edu.au/~steffen/>