The 'dl' interface to the tcl load command using dopen() with RTLD_NOW.
This forces all symbols to be resolved at the time of the dlopen rather
than the time of a reference to that symbol. This poses problems for
dynamically linking two libraries, say A and B, where A uses some code of B
and B uses some code of A.
I don't want to get into the implications of such poor style - I already
know it is. Linking normally using good old '-la -lb' doesn't cause
problems with such mutually-referential libraries. However converting an
application written in such a way (using tkAppInit) to one that uses tclsh
or wish and a bunch of tcl load commands is impossible in this case.
I've changed the dopen in unix/tclLoadDl.c to use RTLD_LAZY instead of
RTLD_NOW. This removes the requirement of all symbols being resolved at the
time of loading and should also be more efficient. With this methods it's
perfectly possible to get this example application to work with the tcl
load commands.
It would appear that LAZY loading is better. However for how many systems
is it possible? I suspect that Windows couldn't cope; as per normal ;-).
It's already nearly (but not quite) impossible to create such mutually
referential libraries under windows anyway.
Time to go and improve on some of my library dependencies I think...
James
PS. Whilst thinking about windows - is it possible to statically link with
tcl/tk in order to produce a single executable for an application (using
tcl, tk and C)? I've tried all sorts of ways (using VC++ 4.0) and I've
pretty much given up. Any advice is most welcome.
--
James Bonfield (j...@mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 412282
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/