Tcl Source Code

The TIP 338 changes to move Tcl_GetStartupScript/Tcl_SetStartupScript out of the internal stub tables but not into the public stub tables break the TkAqua build:
Undefined symbols:
  "_Tcl_GetStartupScript", referenced from:
      _Tk_MainEx in tkMain.o
      _TkpInit in tkMacOSXInit.o
  "_Tcl_SetStartupScript", referenced from:
      _Tk_MainEx in tkMain.o
      _TkMacOSXDefaultStartupScript in tkMacOSXInit.o

the Tk dynamic library is linked with stubs only (i.e. only against libtclstub), so Tcl_GetStartupScript/Tcl_SetStartupScript need to be in the public stub table and not just in tcl.h

Patch committed.

If we need to revisit this during the
beta cycle, that's fine, but for now
we need Tk to build.

Let me just add, that in my view the stubs interface is prefered always
compared to direct function access. It allows embedders to do something
like:
    void *tcl = dlopen("libtcl?.?.so");
    fn *createinterp = (fn *) dlsym(tcl, "Tcl_CreateInterpreter")
    Tcl_Interp *interp = createinterp();
    Tcl_InitStubs(interp, ....);
    ......
All remaining things can be done through the stubs interface,
so only a single symbol needs to be searched in the shared
library. That's why I fully support das' fix.

I even would keep the entries in the private stub table
as well, that would allow to load Tk 8.5 dynamically in
Tcl 8.6. I see no reason to forbid that (neither do I
see a reason to support that, but when compatibility is
_that_ easy to accomplish, why not)

Regards,
        Jan Nijtmans

note that this affects the purely generic code in Tk_MainEx() as well (multiple calls of Tcl_GetStartupScript), i.e. the problem is not specific to TkAqua in fact
for better or for worse Tk_MainEx has had this functionality and has been in the Tk stubs table forever. Beyond backward compat concerns, I'm not a fan of moving all the code in there dealing with startup scripts out in the lean&mean (and currently very easy to understand) tkAppInit.c...

even less so for the gnarly platform-specific code in TkpInit(), that code is interdependent with other internals of the Tk implementation and needs to remain in the library so that its implementation can be changed centrally, and not in a file intended to be statically compiled-in by an embedder.

Moving platform/windowingsystem specific code into tkAppInit.c is also a bad idea because it would complicate the linking of wish/embedders, e.g. the link line would need to change depending on whether TkAqua or TkX11 is being linked against (which is currently not the case, unless linking statically).

IMO those disadvantages far outweigh the minor impurity of having an API intended only for embedders in the stub table.

The motivation to not put the routines
in public stubs was:

1) Not doing so reduced the need to
   get thread safety right.
2) No doing so offered a chance to
   discover non-embedders making calls,
   and either correct that, or learn
   about unmet interface needs.

As it turns out, I took care of 1) anyway.
The routines are thread safe, so there's
not technical reason they can't be put into
public stubs anymore.  Now it's more a matter
of intent.  We intend for embedders to use
these routines.  Public stubs makes them
available to extenders, who we think can
only be disappointed with them.

Looking briefly at the troubles suffered
by Aqua Tk, it appears they come from putting
some code into Tk that ought to be in
wish.  In particular, the [console] machinery
is part of wish, not part of Tk, so I would
expect code that examines whether or not
to enable it would also be part of wish.

The other usage I see is to pull startup
script selection out of a "CFBundle" along
with a platform-specific call to a private
routine within Tk_MainEx() to make that possible.
I think with the new public facility, the way
to accomplish the same thing is to have the
caller of Tk_Main() make that same private
call before calling Tk_Main(), and link
that code to libtcl instead of libtclstub.
So, it also has the same "put it in wish, not Tk"
flavor of solution.

If that's off the track, as I say, the tech
hurdles to exposing the routines in public
stubs are gone, so we can go that way too
if either required, or deemed a more desirable
path in terms of disruption.

I'd like comments from jenglish, but if
he can't review within a day or so, go ahead
and commit your fix.

File Added - 305412: 2431338.diff

attached patch fixes the Tk breakage and corrects some typos in tclInt.decls
File Added: 2431338.diff