Menu
▾
▴
#624 Missing objectfiles in static lib
When building a static tclsh and .lib using makefile.vc, the dde and registry code is not added to the .lib. The attached patch adds those object files to the static .lib.
Aa a side question: what should be done with tclOOStubLib.obj, tclStubLib.obj and tclTomMathStubLib.obj when building a static .lib with makefile.vc? Should they be added to the .lib too?
Add dde an registry object files to static lib
dde and registry are [load]able packages. Not clear to
me why their code ought to be in a static Tcl library.
The other things you mention have dev history as packages,
but they are now simply part of Tcl. Need to be in the Tcl library.
When building with OPTS=staticpkg dde and registry are linked into the tclsh, but should also be in the tcl86.lib to make it possible to embed Tcl into an app with Tcl statically linked, including dde and registry.
tclOOStubLib.obj, tclStubLib.obj and tclTomMathStubLib.obj
are in the stub library tcl86stub.lib. Previously they were in
the static library as well, but not any more since 8.6. That's
on purpose!
Applications linking with OPTS=staticpkg
still can load dde/registry dynamically, or include it in the
build. If you want the latter, you can just add tclWinDde.o,
tclWinReg.o and tclstub86.lib to the link line, then you
have everything.
Would that work for you?
I ship tcl86.lib to customers, having everything in one lib is far easier. Why add it to tclsh and not to the lib? For me OPTS=staticpkgs hints at non-loadable packages present in the lib, not just the tclsh.
In Tcl 8.5's makefile.vc I see:
TCLSHOBJS = \ $(TMP_DIR)\tclAppInit.obj \ !if $(TCL_USE_STATIC_PACKAGES)
$(TMP_DIR)\tclWinReg.obj \ $(TMP_DIR)\tclWinDde.obj \ !endif
$(TMP_DIR)\tclsh.res
To me that means that OPTS=staticpkgs means
that the registry and dde packages should be
added to tclsh.exe, not to tclsh85.lib. Changing
that would be a feature request, not a bug.
Apologies. I overlooked the "StubLib" part of those
filenames.
The *only* purpose of the *StubLib files is to allow an external piece of code to connect to Tcl's API (or the API one of the built-in extensions). Code that's "inside" Tcl (in the same executable) doesn't need stubs; it should be directly bound. There's no point at all in building the *StubLib objects into a Tcl executable; they're just for extension DLLs.
Feature or bug, I perceive it as a bug in the way I need the lib to be built so I can distribute it. Without this change, I'd need to ship the lib and some .obj files or make the change to the makefile after each release. I don't see much use for having the dde and registry .obj not in the .lib.
So, let's make it a feature request ;-)
Actually, I don't have a problem really
with putting tclWinReg.o and tclWinDde.o
in the static library when OPTS=staticpkgs
is specified. However putting the
tcl*StubLib.obj files in it is
problematic! This means that
there are multiple static libraries
with the same symbols.
This means that you should
distribute two static libraries
(the normal one and the stub
library) to your clients, both
should be linked against
is dde and registry functionality
is desired.
Would that work for you?
OK, thanks. About the *stub* file: I was only asking as I was not sure when they are needed. It's OK not to have them in the static lib for me.
Committed to frq-3544967 branch for testing
Tested OK for me.
Well, I'm not 100% satisfied yet. If we put tclWinReg.obj
and tclWinDde.obj in the static lib using makefile.vc, we
should do the same with Makefile.in as well.
committed that to frq-3544967 now, with some comment
updates in makefile.vc. Still needs more testing before
being merge to trunk. (Anyway, I want to wait on
Tcl 8.6b3 before doing that, preventing any risk
on delay for the b3 release)
I understand. I appreciate your support.
Merged to trunk now.
> (Anyway, I want to wait on Tcl 8.6b3 before doing that,
> preventing any risk on delay for the b3 release)
It works well, with minimal risk, and doing this now
gives more time for testing for the b3 release. Since
there are other test failures being investigated now,
I don't think this will delay 8.6b3.