#1055 Tk library & external dependences

[Georgios Petasis]

Imagine the following usage scenario:

In an application you want to embed Tcl/Tk. Due to various installation
reasons, you don't want to provide new binaries with each tcl/tk update,
but give the user the freedom to use any tcl/tk version he wishes, without
the need to also update the app.

The only solution to this, is to load and initialise tcl/tk dynamically,
at run time, without linking with either the tcl or tk library during the
compilation of the app.
The app can use LoadLibrary or dlopen (or what ever else) in order to
load the tcl library into the app and initialise tcl. This is feasible
without any problem.
Doing the same with the tk library is not possible, as the tk library,
at least under unix, has dependences over the tcl lib, mainly regarding
the symbol tclStubPtr. Runing ldd on my solaris system with 8.4a3 gives:

ldd -d libtk8.4.so
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libX11.so.4 => /usr/lib/libX11.so.4
libdl.so.1 => /usr/lib/libdl.so.1
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libXext.so.0 => /usr/lib/libXext.so.0
libdga.so.1 => /usr/openwin/lib/libdga.so.1
symbol not found: Tcl_Free (./libtk8.4.so)
symbol not found: tclStubsPtr (./libtk8.4.so)
/usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1

Although tk uses stubs and initialises them in Tk_Init,
it seems that tk library requires an external tclStubsPtr, from the
tcl library.
What's odd is that tclStubsPtr is really in
tclstub8.4.a which libtk was linked with and should NOT be referred to over in
libtcl. Stubs was supposed to make all that blind and not have any load-time
dependencies.

This bug is originated by a post in comp.lang.tcl,
(http://groups.google.com/groups?hl=en&safe=off&threadm=3B8DE6E3.3B588DA%40iit.demokritos.
gr&rnum=1&prev=/groups%3Fq%3D%2B%2B%2B%2B%2B%2B%2B%2B%2BDynamic%2BLoad%2B
of%2BTk%2Bfails%252C%2BUndefined%2BSymbol%2BtclStubsPtr%26meta%3Dsite%253Dgroups)

or search groups.google.com for "Dynamic Load of Tk fails, Undefined Symbol tclStubsPtr"

A workarround reported in this group is:
" realized that when imbedding Tcl and Tk into another application, and
dynamically loading their libraries (to avoid a version dependency), on
Linux I needed to use the RTLD_GLOBAL flag on the dlopen so the Tcl
symbols would ba accessable to the Tk library." - David Liebtag

Under windows the bug does not seem to exist, although the actual
code that loaded the library was not posted. Perhaps it included such a
workarround?

[Georgios Petasis]

Logged In: YES
user_id=92283

David Gravereaux has confirmed that the bug does not affect windows:

"Just for a deeper gander, I looked at tk84.dll and looked at the imports:

$ dumpbin tk84.dll /imports
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

Dump of file tk84.dll

File Type: DLL

Section contains the following imports:

USER32.dll
GDI32.dll
comdlg32.dll
MSVCRT.dll
KERNEL32.dll

No problem on windows."

[Donal K. Fellows]

Logged In: YES
user_id=79902

Is this something to do with the lack of a -ltclstub8.4 line
in the appropriate part of the makefile? I must admit to not
fully comprehending all the fine details of the way the stub
system is supposed to be built...

[Daniel A. Steffen]

Logged In: YES
user_id=90580

Jeff, can you take a look at this? not really my area of
expertise...

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

This was either fixed in 8.4a4cvs or may have been a local
build problem. I get:

sparcu10 [~/build/tk84] 52 > ldd ./libtk8.4.so
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libX11.so.4 => /usr/openwin/lib/libX11.so.4
libdl.so.1 => /usr/lib/libdl.so.1
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libXext.so.0 => /usr/openwin/lib/libXext.so.0
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1