From: SourceForge.net <no...@so...> - 2009-11-24 20:20:29
|
Bugs item #2902965, was opened at 2009-11-24 07:56 Message generated for change (Comment added) made by nijtmans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2902965&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 40. Dynamic Loading Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Nijtmans (nijtmans) Assigned to: Jan Nijtmans (nijtmans) Summary: stub related changes cause tclkit built to break Initial Comment: Pat reported me the following. I didn't expect those changes to cause such problems. This issue is meant to work out a solution, for everybody to comment on. Pat Thoyts: I'm not sure this is correct. You now force the dde and registry extensions to use stubs at all times - even when building static. tclkit links static versions of these into the tclkit executable so now I get a link error for unresolved symbol _tclStubsPtr from tclWinDde.obj and tclWinReg.obj when linking the tclkit executable. Obviously I can add the tcl stubs library to the linker command line but really should I need to? Surely in a static binary like this I should only be exposing the stubs interface - not making use of it internally. The original bug you were fixing is irrelevant to the tclkit build as when we construct the vfs we manufacture a static pkgIndex so that package require does the right thing. ie: package ifneeded dde 1.n.n {load {} dde} I could well be wrong, but surely when building a static version of dde/registry I don't need the macro getting undef'd on me. Also, if this breaks tclkit I think we can be sure it will break other builds of embedded tcl elsewhere. ---------------------------------------------------------------------- >Comment By: Jan Nijtmans (nijtmans) Date: 2009-11-24 21:20 Message: >Should I conclude then, that after >we had completed taking tclStubsPtr >out of libtcl, you are putting it back in >again ?!? No! For shared libraries nothing changes. Previously, there were two tclStubPtr variables, one in the shared library, another in the static stub library. That is dangerous, because when static and shared libraries are mixed, it is system dependant what will be the result. There were two different object files which declared the same variable, and that is dangerous. What I want to do is putting the stub library in the static library as well. Still it depends on the situation which objects is included in the final executable: the one from the stub library or the one from the static library. But this time it doesn't matter because both object files are exactly the same! So, the dangerous situation from before is still gone. We can mix static and shared libraries at will, it simply will work always. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2009-11-24 20:41 Message: ??? Haven't examined the patch yet. Just reacting to the last comment. Should I conclude then, that after we had completed taking tclStubsPtr out of libtcl, you are putting it back in again ?!? ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2009-11-24 12:23 Message: OK, here is the fix. Explanation: The reason for the stub changes is to make it possible to build both a static tclreg12.lib and a tclreg12.dll next to each other (and the same for tcldde13.lib/tcldde13.dll). Then we can do the same with the future tcltest86.lib/tcltest86.dll. We would need to compile two tclWinReg.obj files, one compiled without and one compiled with stubs. It's a lot easier to reduce this to only one, it has the advantage that tclreg12.lib can be linked in any tclsh, no matter it is compiled against tcl86.dll or tcl86.lib. Any combination of static and shared libraries will work! The disadvantage is that every executable which includes a single static library will need to link with the stub table as well. Solution: Include the stub library in any static library we produce. Then linking with any static library will automatically include the stub library objects as well. This fixes the tclkit build. proposed patch attached to this issue (/win directory only, in /unix similar changes have to be made) The modification to tclAppInit.c is not necessary, it only makes that tclsh not is forced to link with the stub library, it is completely initialized as well. So, even extensions that are compiled with TCL_USE_STUBS bug forget to call Tcl_InitStubs() will still work. It is meant as an extra safety net. With those changes, it's impossible to produce non-working static executables! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2902965&group_id=10894 |