From: SourceForge.net <no...@so...> - 2008-03-20 03:02:20
|
Bugs item #1920030, was opened at 2008-03-19 12:01 Message generated for change (Comment added) made by jenglish You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1920030&group_id=12997 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: 88. Themed Tk Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Joe English (jenglish) Assigned to: Daniel A. Steffen (das) Summary: Ttk stubs table Initial Comment: Re: recent change to unix/Makefile.in: | Author: das <das> 2008-03-19 10:21:47 | Committer: das <das> 2008-03-19 10:21:47 | ttkStubLib.o needs to be in tk library as well as stub library Why is this needed? See also #1819422. From talking with dgp, I think the consensus is that extensions should _either_ compile with -DUSE_FOO_STUBS and link with libfoostub.a, _or_ compile without -DUSE_FOO_STUBS and link directly against libfoo.a. There is no need, as far as I can tell, for TtkInitializeStubs or the rest of the stub mechanism to be included in libtk.so, and in fact this will break other linkage mechanisms (in particular any dependent extensions that link against Tile's stub library instead of Tk's). ---------------------------------------------------------------------- >Comment By: Joe English (jenglish) Date: 2008-03-19 20:01 Message: Logged In: YES user_id=68433 Originator: YES | reread your own comments in 1716117... The issue in #1716117 was existing extensions that (contrary to recommendations) compiled with -DUSE_{TCL|TK}_STUBS but did not link with -l{tcl|tk}stub. AIUI, the resolution for 1716177 was that this mode of operation does not need to (and should not) be supported, but that 8.5 was the wrong time to break this particular mode of operation. Fortunately (sort of), there are no legacy issues wrt. the Ttk stubs table -- the only known extant extension dependent on the Ttk stubs table does not work with Tk 8.5.0 or Tk 8.5.1 anyway (see #1863007). ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2008-03-19 14:06 Message: Logged In: YES user_id=90580 Originator: NO reread your own comments in 1716117... while I certainly agree with the general sentiment that extensions "_either_ compile with -DUSE_FOO_STUBS and link with libfoostub.a, _or_ compile without -DUSE_FOO_STUBS and link directly against libfoo.a" this does not work for static linking with Tk currently due to the legacy presence of tkStubLib.o in libtk, which makes it impossible to link with both -ltk and -ltkstubs due to duplicate symbols from the tk stubs tables. This is not a mode of linking supported for other extensions, so the general stub lib rules don't really apply... So the only way to get the symbols from ttkStubLib.o when needing to link with -ltk is for them to be included in the tk library itself, hence my change (you reverted my tclStubLib and tkStubLib MODULE_SCOPE changes in 1716117 yourself for exactly that same reason...) It's an all or nothing affair, once we remove the tkStubsPtr vars from libtk in 8.6, ttkStubsPtr can go as well, but it does not work to only have some but not all symbols from libtkstub in libtk... The only other possibility would be to build ttkStubLib.o into its own static library libttkstub.a and doc that this needs to be linked along with -ltk (but _not_ -ltkstub until 8.6) when linking statically with tk and extensions using ttk stubs, not a good solution IMO... I don't quite see how this change could break the other linkage mechanisms you mention, can you elaborate? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-03-19 12:11 Message: Logged In: YES user_id=80530 Originator: NO This is similar to 1819422, I think. Our plan was to get the *StubsPtr variables out of the shared libraries during 8.6 development, but the project had too much need for trial and error and testing to attempt in a patch release. I think it's a mistake to copy this pattern, and give us yet another thing to undo. Don't put ttkStubsPtr into libtk without a really good reason and no other reasonable solution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1920030&group_id=12997 |