Repository navigation
Tkinter not installed correctly on Windows 3.15.0b2 #150836
Description
Activity
- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error3.15bugs and security fixesbugs and security fixes
on Jun 3, 2026 import turtlealso works.turtle.Screen()(with the ()s) fails.I was able to get Tkinter working with an install of 3.15.0b2 on Windows by adjusting the files in the tcl directory.
Specifically in the tcl directory I:
- Extracted the contents of
libtcl9.0.3.zipandlibtk9.0.3.zip. - Renamed the tcl_library directory to tcl9.0
- Renamed the existing tk9.0 directory to tk9.0.orig (this could likely be done differently, either deleting or merging)
- Renamed the tk_library to tk9.0
The root issue seems to be that the tcl-tk binary release for 9.0.3.0 uses TclVFS for the tcl and tk libraries which is causing an issue, although the tcl library seems to load fine from the zip file.
- Extracted the contents of
@zware FYI (you can have first go at it, but if you haven't got the time then just say and I'm sure someone else will have time)
Reacted by Zachary WareIf someone can beat me to it, go for it :)
FWIW I think the Tcl library loads because it is embedded in the DLL:
❯ file tcl90.dll tcl90.dll: PE32+ executable (DLL) (GUI) x86-64, for MS Windows ❯ unzip -l tcl90.dll | grep init.tcl warning [tcl90.dll]: 2242048 extra bytes at beginning or within zipfile (attempting to process anyway) 24348 05-12-2026 04:33 tcl_library/init.tclA bit more information. The tk_library is embedded in
tcl9tk90.dll:❯ unzip -l tcl9tk90.dll | grep tk.tcl warning [tcl9tk90.dll]: 1835520 extra bytes at beginning or within zipfile (attempting to process anyway) 7634 05-12-2026 04:33 tk_library/safetk.tcl 27570 05-12-2026 04:33 tk_library/tk.tcl 6667 05-12-2026 04:33 tk_library/ttk/ttk.tclThe DLLs directory does not seem to be searched by Tcl's tcl_findLibrary. Moving
tcl9tk90.dllup one directory so it is next to python.exe fixes the issue but is not a solution.Building tcl/tk with
noembedlooks promising. I'm trying that out locally.Reacted by Zachary WareBuilding Tcl/Tk with the
noembedoption copies the Tcl and Tk core library scripts into the install target using the same layout as Tcl/Tk 8.6, e.g.<arch>/lib/{tcl,tk}9.0/. This allows tkinter to find these script at runtime.The default
embedoption embeds a zip archive with these scripts into the DLLs themselves. This leads to the issue observed here as Tcl does not search the Tk DLL for scripts.nibedanmohanta9-arch commented
on Jun 5, 2026 on Jun 5, 2026 · Hidden as low-qualityshow commentMore actions7 remaining items
Thanks @jjhelmus, I like how that looks, and it ought to be more future proof, if I understand correctly? Interested in others' thoughts as well.
I'll leave a comment or two on that PR, since I think it's worth making it ready to merge, but my other big question is whether this should be used on all platforms? Is this a Windows-only feature from Tcl, or is there benefit to mounting it on all OSs?
my other big question is whether this should be used on all platforms? Is this a Windows-only feature from Tcl, or is there benefit to mounting it on all OSs?
I suspect other platform would benefit from mounting the Tk DSO/DLL if it contained an embedded tk_library. Especially if the CPython install is relocated or determined at install time rather that build time. I need to do some testing to see if the current situation causes problems. Most distributions I know of either us a hardcoded path to the Tk library (e.g. Linux distro provided CPython) or disable embedding (python-build-standalone, MacPorts) which avoids the issue seen here.
Reacted by Steve DowerI tested out linking Tcl/Tk with embedded library on both macOS and Linux in python-build-standalone and neither have issues with Tkinter, it seems like this issue is limited to Windows.
Specifically Tcl uses the executable relative fallback in
tcl_findLibraryto find the DSOs with the embedding in<prefix>/libwhen the executable (python) is in<prefix>/bin.Well, it sounds like @jjhelmus has the only opinion here (other than me), so let's go with doing the mount on Windows only and see what comes out of it.
Reacted by Zachary Ware and Hugo van KemenadeReacted by stonebigThanks all, I've removed the release-blocker label.
Closing this as completed, we can reopen if it is still busted.
Reacted by stonebig- moved this from Todo to Done in Release and Deferred blockers 🚫
on Jun 22, 2026 IDLE is working fine. There is still an open PR. Was it superceded? Should it be closed?
IDLE is working fine. There is still an open PR. Was it superceded? Should it be closed?
Yes, and not yet (unless you're confident enough that this fix will work after install to go and close the other one).
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsDone
Bug report
Bug description:
3.15.0b1 was fine. 3.15.0b2 will not start tk/tcl. Difference must be incomplete upgrade to tk 9.0.
If I run the REPL with either the Start icon or
pyin a console,import tkinterworks but a subsequentt = tkinter.Text()fails withThis probably means that tk wasn't installed properly.
The IDLE icon in the start menu does not work. If I pin it to taskbar and click, the blue circle starts and quickly stops. The one for older versions start, quickly stop, and quickly restart until IDLE runs. In a console,
py -m idlelibfails at the same _tkinter.create(...) call with the same message.I have seen a similar message before and I believe the list of directories is obsolete. In a local build, I believe the tcl/tk file needs to be in PCbuild/. My 3.16 build works fine. Installations used to have DLLs/tcl86t.dll and tk86t.dll. 3.15.0b2 has tcl9tk90.dll and tcl90.dll (no t suffix). Is _tkinter.dll looking for those names?
CPython versions tested on:
3.15
Operating systems tested on:
Windows
Linked PRs