I installed in Anaconda the tk package which is 8.6.10. I run Python 3.8.5
When I run within Spyder IDE the simple script
import tkinter as tk
win = tk.Tk()
I got the classic message "TclError: Can't find a usable init.tcl in the following directories:"
In the list of directories reported I do have tcl.
I tried in the cmd from anaconda to run tclsh and wish and they are both working. By running wish and looking for the version it reports correctly Tcl and Tk 8.6.10
So I took the C:\ProgramData\Anaconda3\Library\lib\tcl8.6\init.tcl and moved it in C:/ProgramData/library as this is one of the directories I get in the error report.
When I do this I got another error "C:/ProgramData/library/init.tcl: version conflict for package "Tcl": have 8.6.9, need exactly 8.6.10"
So it is clear that the tclsh in bin and the init.tcl are not from the same version (why?) but how can now enforce a correct behavior of my python script looking for the right Tcl/Tk?
I was expecting this to work out of the box
p.s. THe directory "C:\ProgramData\Anaconda3\Library\lib\tcl8.6" is also in the list of directories that is returned by the error.
The problem is that the version of the DLLs that are being used (which might be TCL86.DLL and TK86.DLL on Windows, but the exact names can vary) must match exactly the version of their support files (the primary one is init.tcl, but there's a lot more besides). That's a hard requirement; the software checks it (rightly!) and definitely won't work without them. As the binary code is looking for the files from 8.6.9 and yet has the files from 8.6.10 (a version mismatch) it's not going to work. (I don't know exactly how Tkinter was built.)
But at least we know what files it is looking for, and exactly where to get them. The official release of Tcl and Tk 8.6.9 is at https://sourceforge.net/projects/tcl/files/Tcl/8.6.9/ so get tcl869-src.zip and tk869-src.zip from there, and copy the contents of the library directory in each ZIP to where you want them to be (presumably one of the directories that are searched for). You don't need to do anything fancier than that, except perhaps to delete the old mismatched files if they're earlier on the path.
Related
I was GOING to ask for help with this annoying problem, but I have solved it and want to document the stupid solution for the next person who searches SO for the string __cg_jpeg_resync_to_restart and gets (literally) 47 hits.
Here's the problem: on attempting to use tkinter for the first time with Python3, the following error may occur when you import tkinter:
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/Current/lib/python3.8/lib-dynload/_tkinter.cpython-38-darwin.so, 2): Symbol not found: __cg_jpeg_resync_to_restart
Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
Expected in: /usr/local/lib/libJPEG.dylib
in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
Python doc is clear that 3.7+ contain their own copy of tkinter, and in fact the first line above confirms that. So the issue isn't a wrong version of tkinter or some other tkinter install issue. But tkinter is trying to link to the MacOS copy of ImagIO, and that is trying to dynamically link what should be a perfectly standard thing, libJPEG.dylib. However that lib apparently doesn't define an entry point __cg_jpeg_resync_to_restart that ImagIO expects.
Now what?
This sounds like a version mismatch, ImageIO is getting a JPEG lib of a different version than it expects. But why? I check using homebrew, I have the very latest jpeg (9), it is in /usr/local/lib/libjpeg.dylib. That's odd, the name is all lowercase? I tell homebrew to uninstall its version of the jpeg cask, and it will not do that because libjpeg is a prereq of ghostscript, imagemagick, and about 6 other things brew has installed.
Most of the SO hits on __cg_jpeg_resync_to_restart talk about re-aiming DYLD_LIBRARY_PATH various ways and in fact that is the solution. After over 3 hours of futzing around, trying to find other versions of libjpeg, I finally look in the one place that is called out in the message(!),
$ find /System/Library/Frameworks/ImageIO.framework -name '*.dylib'
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libOpenEXR.dylib
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
Bingo. Look, it even uses capital letter JPEG in the name, as in the message! The ImageIO distributed with MacOS has its own private collection of libs, and when I set DYLD_LIBRARY_PATH for Python's use, I confused it. Adding /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources at the head of DYLD_LIBRARY_PATH before starting Python3 and tkinter imports fine!
It remains to be seen if other modules that expect libjpeg.dylib version 9 are going to barf now. Or will they ignore libJPEG and go on to /usr/local/libjpeg? I would appreciate comments on that and any issues here.
I am running linux and python 2.7.14 I have successfully installed the binary version of tcltk. I installed it into the same directory as python27 such that the following directories were all added in the same folders, namely: include, lib, etc. The bits were not all found when I configured python again so when I checked the setup.py file it mentioned I could do the following, which I did:
make clean
./configure --with-tcltk-includes="-I/home2/bishopk2/python27/include" --
with-tcltk-libs="-L/home2/bishopk2/python27/lib/tcllib1.18 -ltclm.n -L/
home2/bishopk2/python27/lib/tklib0.6 -ltkm.n"
make TCLTK_INCLUDES="/home2/bishopk2/python27/include"
TCLTK_LIBS="/home2/bishopk2/python27/lib"
I have tried all permutations of this (i.e., with and without the tcllib1.18, ltclm.n, etc., etc.)
I am not sure the best way to share a config.log on stack overflow but here is a link:
https://www.pharmacoengineering.com/share-a-file/
(I made the pdf downloadable)
I had to save it as a pdf file so that it would upload to wordpress.
When I looked at it, I am not sure why the tcl.h file could not be found because when I:
find . -name "tcl.h"
It says that it is in my /home2/bishopk2/python27/include folder.
All of the libraries are there and it should be able to connect Tkinter with my tcl and tk libraries.
Any help would be greatly appreciated.
Best wishes,
Corey
tcllib and tklib and libraries of Tcl scripts.
To build tkinter you need to link to the binary shared object library (a .so file). This should be named libtcl8.6.so or something similar. It is not clear from your post that you realize tclM.N is a way of saying Major number, Minor number but you should put the numbers in for your installed version. So on my Debian based system I will provide --with-tcltk-includes=/usr/include/tcl8.6 --with-tcltk-libs=/usr/lib/x86_64-linux-gnu given your example. If you need to put in the library name then -ltk8.6 -ltcl8.6 (the linker drops the lib prefix from the filename.
I'm using python 2.7.9 and encountered a problem when installing pygtk.
It displayed "Runtime error!...R6034 An application has made an attempt to load the C runtime library incorrectly" when installing numpy/scipy after pygtk being installed.
I tried to figure it out by searching it in stackoverflow and found two similar questions: Runtime error R6034 in embedded Python application and An application has made an attempt to load the C runtime library incorrectly.
So following the first one, I deleted the path corresponding to msvcr90.dll, however, it still cannot work. Then I chose to simply delete msvcr90.dll; at this time, this error wasn't presented when installing numpy/scipy, however, these two modules cannot work when simply typing "importing numpy/scipy".
I also renamed gtk-2.0 following the second one. Then numpy and scipy can be successfully installed. But it displayed "Error processing line 3 of C:\Python27\lib\site-packages\pygtk.pth" when installing matplotlib using pip.
I'm really confused about it. Can anybody provide some methods to fix it?
I've installed Python and PyGTK on 5+ machines, at least two of them brand new, clean builds of Win 7.
I've got the An application has made an attempt to load the C runtime library incorrectly error whenever I install a Python package as a windows installer (rather than using pip) on all these machines. It's annoying, but has never made a jot of difference, both Python and Gtk function correctly.
You've deleted msvcr90.dll, and that is why you get your Error processing line 3... If you look at this file, you'll see that line 3 is import runtime, and if you look further into the 'runtime' package, you'll see that this then tries to find the missing dll.
I think your best bet is to try to restore the missing file. If it's still in your recycle bin - great!
If not, the best thing to do is reinstall the Visual C++ runtime library
I made this video to show my way: https://www.youtube.com/watch?v=s6jhR1VBfeU. I use Anaconda to embedded Python in my C++ application. I simply changed "msvcr90.dll" to "msvcr90.dll_hihi" in 3 folders:
C:\Users\your user\Anaconda2\Library\bin, C:\Users\your user\Anaconda2 and C:\Program Files\Intel\iCLS Client (for x64)
I am trying to compile a program (python2.7) but no matter what I do I keep getting this error:
C:/Python27/tcl/tk8.5/tk.tcl: version conflict for package "Tk": have 8.5.2, need exactly 8.5.15
version conflict for package "Tk": have 8.5.2, need exactly 8.5.15
while executing
"package require -exact Tk 8.5.15"
(file "C:/Python27/tcl/tk8.5/tk.tcl" line 18)
invoked from within
"source C:/Python27/tcl/tk8.5/tk.tcl"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list source $file]"
This probably means that tk wasn't installed properly.
Can someone please explain to me what's the problem here?
step 1: open C:\Python27\tcl\tcl8.5\init.tcl
if {[info commands package] == ""} {
error "version mismatch: library\nscripts expect Tcl version 7.5b1 or later but the loaded version is\nonly [info patchlevel]"
}
package require -exact Tcl 8.5.15
8.5.15 changed to 8.5.2
step 2: open C:\Python27\tcl\tk8.5\tk.tcl
package require Tcl 8.5 ;# Guard against [source] in an 8.4- interp before
;# using 8.5 [package] features.
# Insist on running with compatible version of Tcl
package require Tcl 8.5.0
# Verify that we have Tk binary and script components from the same release
package require -exact Tk 8.5.15
8.5.15 changed to 8.5.2
Tk comes in (conceptually) two pieces:
the dynamic library file that implements the views
the script library file(s) that implements the default controllers.
These must be exactly matched to each other (it's the only way in which they are warranted to work correctly). By default, the Tk DLL includes the path where it can find its scripts, but it can be overridden by environment variables; that mechanism is mainly intended to support pre-installation testing, though sometimes it gets used rather more than it really ought.
You appear to have configured things so that you have one version of the DLL (8.5.2) whereas a different version of the scripts (8.5.15). This could be because you've linked against the wrong version of the DLL, or because you have an environment variable (TK_LIBRARY) set to point to the wrong installation. Which it is is a little hard to tell from the error message: all it really says is that there is a version mismatch.
So, I'm trying to get gtksourceview python bindings work under windows (I'm developing a cross platform gtk application that shows code, so gtksourceview seemed like a natural choice).
I have pygtk installed and working (I followed the instructions in http://www.pygtk.org/downloads.html)
I tried the instructions in http://projects.gnome.org/gtksourceview/ for gtksourceview.
Here is what I did:
Downloaded and extracted the latest gtksourceview window binaries from: http://ftp.gnome.org/pub/gnome/binaries/win32/gtksourceview/2.10/gtksourceview-2.10.0.zip
The website said gtksourceview needs libxml, so I downloaded and extracted the latest libxml window binaries from:
http://xmlsoft.org/sources/win32/libxml2-2.7.6.win32.zip
Added the folders containing dll files to the PATH (in my computer they were c:\opt\gtksourceview\bin; C:\opt\libxml2-2.7.6.win32\bin)
Installed pygtksourceview with the windows installer:
http://ftp.gnome.org/pub/gnome/binaries/win32/pygtksourceview/2.10/pygtksourceview-2.10.0.win32-py2.6.exe
Renamed the file libxml2.dll to libxml2-2.dll (after running depends on the gtksourceview dll)
Now, the gtksouceview widget seems to work, until I'm trying to set the code's language. When I do that python crashes.
Here is how I crash it in the console (the simplest way i could come up with):
>>>import gtksourceview2
>>>lang = gtksourceview2.language_manager_get_default().get_language('cpp')
>>>lang.get_style_ids()
I'm hoping I'm not the first person to use gtksourceview in python on windows. Any ideas what I should try?
So in case anyone else is wondering -- I grabbed the wrong libxml dll. The right one is in:
http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/libxml2_2.7.7-1_win32.zip