Menu
▾
▴
#2693 Static compling of 8.6 in msys/mingw
closed-fixed
9
2009-12-10
2009-10-09
No
I tried compiling 8.6 from the cvs in a msys/mingw enviroment using the --disable-shared option.
Tcl went well but compiling Tk failed with the message:
gcc -O2 -fomit-frame-pointer winMain.o "/c/tmp/TclKitLite/tcl-8.6/tcl/win/libtcl86ss.a" libtk86s.a -lws2_32 -lgdi32 -lcomdlg32 -limm32 -lcomctl32 -lshell32 -luuid -lole32 -loleaut32 \
wish.res.o -o wish86s.exe -mwindows
libtk86s.a(tkWindow.o):tkWindow.c:(.text+0x18): undefined reference to `tclStubsPtr'
libtk86s.a(tkWindow.o):tkWindow.c:(.text+0x4f): undefined reference to `tclStubsPtr'
[...]
Should it be trying to use stubs in a static build?
Is this problem limited to 8.6, or does 8.5.7 or 8.5.8 suffer
from the same problem?
Tcl/Tk 8.5.7 compiles fine with --disable-shared. I don't really know how to get 8.5.8 out of cvs.
8.5.8 hasn't been released yet. Best approximation right now is the tip of the core-8-5-branch.
I'm sure this one is introduced by [Bug 1819422]
"tclStubsPtr out of libtcl", so it is indeed limited
to 8.6 only. I guess it is Windows specific as well,
as UNIX is less critical in this respect. Maybe
this change (a good one, in my view!) should
have been marked with POTENTIAL
INCOMPATIBILITY, because it might be
that other extensions need to be be modified
when they make the same mistake as Tk,
assuming that tclStubsPtr is available in
libtcl.a
From the Tcl changes file:
2008-04-01 (interface)[1819422] tclStubsPtr no longer in libtcl (porter)
*** POTENTIAL INCOMPATIBILITY ***
From the 8.6a1 release notes:
" * C code compiled with USE_TCL_STUBS now must be linked against a
stub library. The Tcl shared library no longer exports variables
used in the stub interface. Analogous changes also made to Tk.
*** POTENTIAL INCOMPATIBILITY ***
"
So is something still broken in HEAD of Tk, and if so what is
it and how do we fix it?
Yes, I reproduced it, so there indeed is something broken in HEAD. Preparing a patch now.
fix for Bug #2875562
OK, here is the fix. In fact we have a choice whether we compile libtk.a with or without stubs. Compiling with stubs has the advantage that the same libtk.a
can be linked with either libtk.a and libtk.so.. If we compile libtka. without
stubs, then it needs to be linked with libtcl.a if tcl was compiled statically
and it needs to be linked with libtcl.so if Tcl was compiled dynamically.
But the disadvantage is that every application or extension which links
with libtk.a needs to link with libtclstub.a as well.
Pat, do you agree with this approach? If you want, you
can assign it to me then I will check this in. Or you
can evaluate it and do it yourself. Whatever you prefer.
An improvement could be to make tclStubLib.o and
tclOOStubLib.o part of libtk.a. Then applications who
link with libtk.a don't have to link with libtclstub.a any
more. But that's not trivial.
FWIW, I *only* support stubbed linking with the TclOO API.
Fixed in HEAD (Makefile.in 1.85). I don't undertand the remark about stubbed linking with the TclOO API. Tk doesn't use the TclOO API,
this change only potentially involves extenions with involve Tk
(expecttk, blt ....), and only when linking with the static Tk library
(as in starpack's). Please review, anyone who feels like it!
At least the bug is fixed, but further improvements are possible,
therefore leaving the issue open.
Thank you, tk now compiles and install fine.
But, could please check whether 'package require registry' works for you? In my case, pkgIndex.tcl doesn't get created for the extension while it is when compiling with shared libraries.
Thanks
Reply to Andres:
That's true, but it's an unrelated Tcl bug, which
probably affects Tcl 8.5 as well. Therefore, I
created a new [Tcl Bug #2883850]:
"pkgIndex.tcl doesn't get created with static Tcl build"
Was already fixed in HEAD. The only reason it was left open was to give Pat
Thoyts a chance to review it. Closing now, but if Pat has remarks then
please re-open it.