ERROR: could not find TCL/TK

[Lynn Oliver]

I'm running Python 2.7.2 on OS X 10.7.3.  I downloaded the current dev version of pyinstaller this evening.  When I run  pyinstaller.py, I get:

ERROR: could not find TCL/TK

Building in debug mode and running the resulting app gives me, as you might expect:

ImportError: dlopen(/var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIlWWvbW/_tkinter.so, 2): Library not loaded: @executable_path/Tcl

Looking at sys.path, I see:

/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk

Which pyinstaller module is issuing the "ERROR: could not find TCL/TK" message?

Any suggestions for tracking this down?

Thanks...

Lynn

[Hartmut Goebel]

Hi Lynn

Which pyinstaller module is issuing the "ERROR: could not find TCL/TK" message?

PyInstaller/hooks/hook-_tkinter.py

Any suggestions for tracking this down?

You may hava a look at find_tk_darwin in the hook or bindepend.selectImports

-- 
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP

Goebel Consult 
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult ist Mitglied bei http://www.7-it.de

[Martin Zibricky]

Lynn Oliver píše v Ne 11. 03. 2012 v 21:53 -0700:

> Building in debug mode and running the resulting app gives me, as you
> might expect: ImportError:
> dlopen(/var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIlWWvbW/_tkinter.so, 2): Library not loaded: @executable_path/Tcl
>
> Looking at sys.path, I
> see: /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk
>
> Which pyinstaller module is issuing the "ERROR: could not find TCL/TK"
> message?

Function find_tk_darwin is looking only in system wide Tcl/Tk
installation. Not in the paths from Homebrew / Macports or similar
packaging systems.

This has to be probably fixed to work with python from Homebrew /
Macports.

PyInstaller/hooks/hook-_tkinter.py

37 TCL_root =
"/System/Library/Frameworks/Tcl.framework/Versions/Current"
38 TK_root =
"/System/Library/Frameworks/Tk.framework/Versions/Current"

[Lynn Oliver]

I tried rebuilding Python2.7 from source code using the --enable frameworks option, and while I got a few complaints about missing bits it built and runs.  That built a new _tinkter.so, which I hoped would now point to the existing framework installs of Tcl and Tk.  I modified hook-_tkinter.py to use my libraries:

       TCL_root = "/Library/Frameworks/Tcl.framework/Versions/Current"

        TK_root = "/Library/Frameworks/Tk.framework/Versions/Current"  

It still complains about not finding TCL/TK.  I haven't figured out how to tell where _tkinter.so is going for Tcl.  I tried rebuilding Tcl and Tk; Tcl builds but Tk doesn't, apparently due to something related to 64 bit and aqua.  

At this point I haven't solved the original problem, and now my program doesn't run at all due to not having all the other libraries it needs.  I took a whack at installing everything and was reminded what a pain it was to get this stuff all working in the first place.  After eight or so hours of this I gave up and restored back to where I was this morning, so now my program runs again.  (Just to make it more fun, for the first four hours I was working on this, I was on the phone with Microsoft support getting bounced back and forth.  They couldn't get that problem solved either).

By "This probably has to be fixed," are you suggested that support needs to be added to pyinstaller itself?  Do I have any options for getting this to work with my current installation of Python and associated libraries?

Thanks,

Lynn

[Hartmut Goebel]

Am 13.03.2012 01:02, schrieb Lynn Oliver:

By "This probably has to be fixed," are you suggested that support needs to be added to pyinstaller itself?

Well, I think, this would be the best solution. Otherwise anybody using Homebrew or Macports would have to go through compile-orgies, too.

Do I have any options for getting this to work with my current installation of Python and associated libraries?

Not being a Mac-user, I'm quite sure, you have.  As marting wrote: find_tk_darwin in PyInstaller/Hook/hook-_tkinter.py is looking for the pathes.You need to test for the Homebrew /Mayports locations there. Should be easy if you know the pathes.

[Martin Zibricky]

Hartmut Goebel píše v Út 13. 03. 2012 v 17:42 +0100:

> > By "This probably has to be fixed," are you suggested that support
> > needs to be added to pyinstaller itself?
>
> Well, I think, this would be the best solution. Otherwise anybody
> using Homebrew or Macports would have to go through compile-orgies,
> too.
>
> > Do I have any options for getting this to work with my current
> > installation of Python and associated libraries?
>
> Not being a Mac-user, I'm quite sure, you have. As marting wrote:
> find_tk_darwin in PyInstaller/Hook/hook-_tkinter.py is looking for the
> pathes.You need to test for the Homebrew /Mayports locations there.
> Should be easy if you know the pathes.

Is there any universal way how to get paths to tcl/tk? Or any idea how
it could be detected properly on Mac?

[Lynn Oliver]

> .You need to test for the Homebrew /Mayports locations there. Should be easy if you know the pathes.

As far as I can tell, the path used to find Tcl is imbedded in _tkinter.so, and I haven't been able to suss out where it is going. Worse, I'm not able to track down any copy of Tcl in the folders used by HomeBrew (/usr/local/Cellar...). Any tips for tracking it down?

[Martin Zibricky]

Lynn Oliver píše v Út 13. 03. 2012 v 10:30 -0700:

otool is installed with XCode.

otool -L /path/to/this/module/_tkinter.so

[Lynn Oliver]

Thanks for the pointer to otool.

Python -v displays the following:

>>> import Tkinter

# /usr/local/lib/python2.7/lib-tk/Tkinter.pyc matches /usr/local/lib/python2.7/lib-tk/Tkinter.py

import Tkinter # precompiled from /usr/local/lib/python2.7/lib-tk/Tkinter.pyc

dlopen("/usr/local/lib/python2.7/lib-dynload/_tkinter.so", 2);

import _tkinter # dynamically loaded from /usr/local/lib/python2.7/lib-dynload/_tkinter.so

# /usr/local/lib/python2.7/lib-tk/Tkconstants.pyc matches /usr/local/lib/python2.7/lib-tk/Tkconstants.py

import Tkconstants # precompiled from /usr/local/lib/python2.7/lib-tk/Tkconstants.pyc

Then:

otool -L /usr/local/lib/python2.7/lib-dynload/_tkinter.so

/usr/local/lib/python2.7/lib-dynload/_tkinter.so:

/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility version 8.5.0, current version 8.5.11)

/Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility version 8.5.0, current version 8.5.11)

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

Updating hook-_tkinter.py with 

/Library/Frameworks/Tcl.framework/Versions/8.5

/Library/Frameworks/Tk.framework/Versions/8.5

Does not resolve the problem. ( I had already tried .../Versions/Current, which is the same thing.)

There must be something else pyinstaller needs to make this work.

Lynn

  

--
You received this message because you are subscribed to the Google Groups "PyInstaller" group.
To post to this group, send email to pyins...@googlegroups.com.
To unsubscribe from this group, send email to pyinstaller...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyinstaller?hl=en.

[Martin Zibricky]

Lynn Oliver píše v St 14. 03. 2012 v 00:16 -0700:

> otool
> -L /usr/local/lib/python2.7/lib-dynload/_tkinter.so /usr/local/lib/python2.7/lib-dynload/_tkinter.so: /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility version 8.5.0, current version 8.5.11) /Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility version 8.5.0, current version 8.5.11) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
>
> Updating hook-_tkinter.py with
>
> /Library/Frameworks/Tcl.framework/Versions/8.5 /Library/Frameworks/Tk.framework/Versions/8.5
>
> Does not resolve the problem. ( I had already
> tried .../Versions/Current, which is the same thing.)
>
> There must be something else pyinstaller needs to make this work.
>

This could probably mean that pyinstaller is not able to handle
frameworks from Mac properly. Files

/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
/Library/Frameworks/Tk.framework/Versions/8.5/Tk

Should be present in the dist directory. Could you please try to copy
these two files to the dist directory and try if your app is running?

If your app starts working with these files in the dist directory then
please create a bug report for this.

I think that the cause is that pyinstaller is collecting only *.dylib
files, but not framework files like those 'Tcl' and 'Tk'. These files do
not end with .dylib extension.

[Lynn Oliver]

I wouldn't think that frameworks is the issue, as I've successfully built with Mac frameworks installs before, but I may be wrong.

After all the attempts to rebuild everything, and then reverting back until things seemed to work, I ended up with changes that caused pyinstaller to fail in finding the python executable.  I got that to work by changing build.py from:

580  elif is_darwin:

586      lib = os.path.join(sys.exec_prefix, 'Python')

to:

586      lib = os.path.join(sys.exec_prefix, 'bin/python')

In my current installation, sys.exec_prefix ends up as "/usr/local"

With that working, I started looking at the Tcl/tk stuff.  In tracing build.py I noticed that, despite the error, /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl and the equivalent tk executable were both being processed during the build.

As posted earlier, the error message comes from hook-_tkinter.py.  The existing code looks like this (error message comes from calling routine):

def find_tk_darwin(binaries):

    pattern = re.compile(r'_tkinter')

    for nm, fnm in binaries:

        mo = pattern.match(nm)

        if not mo:

            continue

        TCL_root = "/System/Library/Frameworks/Tcl.framework/Versions/Current"

        TK_root = "/System/Library/Frameworks/Tk.framework/Versions/Current"

return TCL_root, TK_root

mo = pattern.match(nm) always returns "None", so the continue statement is always taken and the last three lines are never executed.  I'm a little baffled by the re.compile call, but the function is looking for a match with 'Tcl' and then with 'Tk' .

I moved the last three statements out of the for loop, which cleared the error message but didn't really advance my understanding of the problem.

I had been building with '-F -w' options, so I removed the options and built again.  Looking in the dist folder, I see that Tcl and tk are already there, as I mentioned above.  I ran otools on the copy of _tkinter.so there, and got:

@executable_path/Tcl (compatibility version 8.5.0, current version 8.5.11)

@executable_path/Tk (compatibility version 8.5.0, current version 8.5.11)

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

When I execute ..dist/appname.app/Contents/MacOS/appname I get:

ImportError: dlopen(/var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIigFuUi/_tkinter.so, 2): Library not loaded: @executable_path/Tcl

  Referenced from: /var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIigFuUi/_tkinter.so

  Reason: image not found

Which is exactly the same thing I get if I use the original hook-_tkinter.py without alterations. 

../dist/appname/_MEI contains:

drwxr-xr-x  7 lynn  lynn  238 Mar 14 14:45 Tcl.framework

drwxr-xr-x  7 lynn  lynn      238 Mar 14 14:45 Headers

drwxr-xr-x  7 lynn  lynn      238 Mar 14 14:45 PrivateHeaders

drwxr-xr-x  7 lynn  lynn      238 Mar 14 14:45 Resources

-rw-r--r--  1 lynn  lynn  2107080 Nov  7 11:18 Tcl

-rw-r--r--  1 lynn  lynn     5088 Nov  7 11:18 libtclstub8.5.a

drwxr-xr-x  7 lynn  lynn  238 Mar 14 14:45 Tk.framework

drwxr-xr-x   8 lynn  lynn      272 Mar 14 14:45 Headers

drwxr-xr-x  10 lynn  lynn      340 Mar 14 14:45 PrivateHeaders

drwxr-xr-x   6 lynn  lynn      204 Mar 14 14:45 Resources

-rw-r--r--   1 lynn  lynn  2920948 Nov  7 11:20 Tk

-rw-r--r--   1 lynn  lynn    11528 Nov  7 11:20 libtkstub8.5.a

I dont know what @executable_path resolves to at run time, but ../dist/appname also contains a copy of Tcl and tk:

-rwxr-xr-x  1 lynn  lynn  2107080 Mar 14 14:45 Tcl

-rwxr-xr-x  1 lynn  lynn  2920948 Mar 14 14:45 tk

I'm at a loss at to what else to look at right now, so any suggestions would be welcomed.  

Lynn

[Lynn Oliver]

A little more info.  Pyinstaller-1.5.1 works with a framework build and does not include the file hook-_tkinter.py.  It's on my OS X build machine, where I don't touch the build environment, and it is 32 bit.

I'm working on a newer version of that program (the one that builds find) and require several additional libraries (matplotlib, numpy, scipy. scikits.samplerate, etc.)  It's the dependencies of these libraries that has caused some aggravation in getting everything built.  My dev machine is running 64-bit and I'm trying to use a recent dev build of pyinstaller.

Lynn

[Hartmut Goebel]

Am 14.03.2012 23:38, schrieb Lynn Oliver:

I'm a little baffled by the re.compile call,

The pattern-matching is just to keep the code of all three variants (win, darwin, unix) in common .

but the function is looking for a match with 'Tcl' and then with 'Tk' .

I can't see this. The function is trying to match "_tkinter" (which may be wrong).

I'm at a loss at to what else to look at right now, so any suggestions would be welcomed. 

Thanks for all the details, but it made me loose the overview. SO lat's step back:

Tcl/TK support consists of two components:
a) The hook hooks/hook-_tkinter.py for detecting the libs and including the Tcl/Tk file into the dist folder
b) a run-time hook support/rthooks/pyi_rth_Tkinter.py to "activate" the distributed files

So first you'd need to find out if a) is working properly. If this is okay, b) may fail.

[Hartmut Goebel]

Am 15.03.2012 01:11, schrieb Lynn Oliver:

A little more info.  Pyinstaller-1.5.1 works with a framework build and does not include the file hook-_tkinter.py.

hook-_tkinter was introduced *after* 1.5.1. We removed the "special" handling of Tcl/Tk and made it normla hooks like any other modules, too.

Please test the following:

- Check out [d9b704e08e2] (2012-01-01 14:51:47), this should work for you, as this still uses the code like in 1.5.1
- Then check out [2cf1972b9] (2012-01-21 15:22:30), which is the end of the change-series. This should not work.

Then please use git bisect to track down the change introducing the error:
git bisect start
git bisect bad 2cf1972b9
git bisect good d9b704e08e2

Please see the man-page of git-bisect for more information.

If 2cf1972b9 is working, the error is caused somewhere else. In this case, the git bisect sequence should look like
git bisect start
git bisect good d9b704e08e2
git bisect bad HEAD

HTH

[Martin Zibricky]

Lynn Oliver píše v St 14. 03. 2012 v 15:38 -0700:

> I dont know what @executable_path resolves to at run time,

It should resolve to the directory containing
myapp_exe_created_by_pyinstaller

In onedir mode it is ./dist/appname directory.

> but ../dist/appname also contains a copy of Tcl and tk:
> -rwxr-xr-x 1 lynn lynn 2107080 Mar 14 14:45 Tcl -rwxr-xr-x 1 lynn
> lynn 2920948 Mar 14 14:45 tk
>
> I'm at a loss at to what else to look at right now, so any suggestions
> would be welcomed.

What are the depencies of files?

@executable_path/Tcl (compatibility version 8.5.0, current version
8.5.11)
@executable_path/Tk (compatibility version 8.5.0, current version
8.5.11)

otool -L ./dist/appname/Tcl
otool -L ./dist/appname/Tk

What architecture is compiled your _tkinter.so file for? i386 or x86_64?

There could be mismatch in the architecture of _tkinter.so, Tcl, Tk or
the created executable. Please try commands:

$ file _tkinter.so
$ file Tcl
$ file Tk
$ file appname_executable

[Lynn Oliver]

My system started getting kernel panics last night, and I was unable get it to boot properly until I reinstalled OS X 10.7.3.  This pretty much trashed all the dev tools (including the apple SDK stuff), so I've had to do a bunch of reinstalls.  I'm back to getting the same errors, so I will assume for now that the prior troubleshooting still applies.

Here's the info you asked for:

otool -L Tcl

Tcl:

@executable_path/Tcl (compatibility version 8.5.0, current version 8.5.11)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.29.0)

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0)

otool -L tk

tk:

@executable_path/Tk (compatibility version 8.5.0, current version 8.5.11)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.29.0)

/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)

/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)

/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0)

/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)

/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0)

/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.29.0)

/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1038.32.0)

file _tkinter.so

_tkinter.so: Mach-O universal binary with 2 architectures

_tkinter.so (for architecture x86_64): Mach-O 64-bit bundle x86_64

_tkinter.so (for architecture i386): Mach-O bundle i386

file Tcl

Tcl: Mach-O universal binary with 2 architectures

Tcl (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

Tcl (for architecture i386): Mach-O dynamically linked shared library i386

file Tk

Tk: Mach-O universal binary with 2 architectures

Tk (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

Tk (for architecture i386): Mach-O dynamically linked shared library i386

file axeomatic

axeomatic: Mach-O 64-bit executable x86_64

On Mar 15, 2012, at 6:30 AM, Martin Zibricky wrote:

What are the depencies of files?

@executable_path/Tcl (compatibility version 8.5.0, current version
8.5.11)
@executable_path/Tk (compatibility version 8.5.0, current version
8.5.11)

otool -L ./dist/appname/Tcl
otool -L ./dist/appname/Tk

What architecture is compiled your _tkinter.so file for? i386 or x86_64?

There could be mismatch in the architecture of _tkinter.so, Tcl, Tk or
the created executable. Please try commands:

$ file _tkinter.so
$ file Tcl
$ file Tk
$ file appname_executable

[Lynn Oliver]

I'm a novice at git, so I'll spell out what I did in case I screwed it up:

git init

git clone git://github.com/pyinstaller/pyinstaller.git

git fetch git://github.com/pyinstaller/pyinstaller.git

git checkout d9b704e08e2

Ran pyinstaller and got ERROR: could not find TCL/TK

git checkout 2cf1972b9

Ran pyinstaller and got ERROR: could not find TCL/TK

Next I went to the old version of my program, the one that builds fine with v1.5.1.  I get the same errors with both versions as above *in 64-bit*, but if I run in 32-bit, d9b704e08e2 works and 2cf1972b9 fails.

git bisect start

git bisect bad 2cf1972b9

git bisect good d9b704e08e2

Bisecting: 5 revisions left to test after this (roughly 3 steps)

[72875a36453d9ff00e8cb46210db96aa9463ea7d] Yet unused TkPKG and TkTree throw error if used.

I tested this version in 32 bit and it fails.

git bisect bad

Bisecting: 2 revisions left to test after this (roughly 1 step)

[b24adc13eb454a59f6f4aee222cde197c7e32fbe] Replace useTK.py by a normal runtime-hook.

This one fails.

git bisect bad

Bisecting: 0 revisions left to test after this (roughly 0 steps)

[2411de16d11918787abc4a96135d5dbfbb03c4c9] Eliminate useless tcl/tk version-number from dist-data-dir.

This one fails, which I guess makes it the culprit in 32-bit.  

 

Finally, I went back to my current program and tried it with d9b704e0802 in 32-bit mode, but it still generates the TCL/TK error.   

[Hartmut Goebel]

Am 15.03.2012 20:33, schrieb Lynn Oliver:

Thanks for all the work so far. I'm afraid, you'll need to spend some more time :-(

git checkout d9b704e08e2

Ran pyinstaller and got ERROR: could not find TCL/TK

git checkout 2cf1972b9

Ran pyinstaller and got ERROR: could not find TCL/TK

So the bug has been introduced prior to this point -- or caused by something else.

git bisect good d9b704e08e2

d9b704e08e2 failed, you should have marked it as "bad".

You may want to google for a git bisect tutorial for a better undserstanding about what this bisect is about.


You wrote, that your program works fine if packaged using 1.5.1. So please test if v1.5.1 is working in you setup:

git checkout v1.5.1
.. run test

If this works, try the last version v1.5.1 and develop have in common:
$ git merge-base HEAD v1.5.1
bc97fdd23444188f7f359b8ebebb47d8cda9006d
$ git checkout bc97fdd23
... run test

If this works, too, please bisect from there to d9b704e08e2 (which is known to be bad):
git bisect reset
git bisect bad d9b704e08e2
git bisect good bc97fdd23
... continue bisecting

Good luck!

[Lynn Oliver]

You are mixing two sets of tests. I marked it good because it built the old version in 32 bit.   Take another look at what I wrote in sequence while I'm at the dentist ...  

Sent from my iPhone

[Lynn Oliver]

Since this was a bit confusing, let me summarize:

In 64-bit, I get the TCL/TK Error with *all* versions of pyinstaller and with both versions (released and dev) of my program.

In 32-bit, the released version of my program builds successfully with pyinstaller v1.5.1 and with pyinstaller d9b704e08e2.  

The dev version has the TCL/TK error with all versions of pyinstaller and in both 32 and 64-bit.  It differs from the released version mainly in that it imports matplotlib, numpy, scikits.resample, and a few other things.

Using 32-bit with the released version, I ran git bisect, starting with the working build, d9b704e08e2:

git bisect bad 2cf1972b9
git bisect good d9b704e08e2
Bisecting: 5 revisions left to test after this (roughly 3 steps)

[72875a36453d9ff00e8cb46210db96aa9463ea7d] Yet unused TkPKG and TkTree throw error if used

Still fails.

git bisect bad
Bisecting: 2 revisions left to test after this (roughly 1 step)

[b24adc13eb454a59f6f4aee222cde197c7e32fbe] Replace useTK.py by a normal runtime-hook.

Still fails.

git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)

[2411de16d11918787abc4a96135d5dbfbb03c4c9] Eliminate useless tcl/tk version-number from dist-data-dir.

Still fails.

Going back one more change bring me back to d9b704e08e2, so the last change listed appears to introduce a bug.

Finally, I was unable to checkout v1.5.1 from my git clone of pyinstaller 

error: pathspec 'v1.5.1' did not match any file(s) known to git. 

but I did test v1.5.1 as downloaded from the pyinstaller site.

Hope this makes it a bit more clear.

-Lynn

Begin forwarded message:

[Lynn Oliver]

Retrying some things tonight, and I can't repeat what I got this afternoon.

1. Rev version of program builds in 32-bit using v1.5.1, but does not execute.  At first look it appears to be a mismatch between _tkinter.so and the installed Tcl/Tk libraries: "version conflict for package "Tk": have 8.5.11, need exactly 8.5.9"

I ran into this when I was setting up my dev tools the first time, and I recall struggling for some time getting it fixed.

2. git checkout d9b704e08e2 gives me a version of pyinstaller that includes hook-_tkinter.py.  I thought that was included in a later build.

3. Rev version of program does not build using pyinstaller d9b704e08e2  (TCL/TK error).

I need to resolve the _tkinter.so build before I can do anything further on this.

Begin forwarded message:

[Lynn Oliver]

Taking a step back, here is where I am currently.

1. I can build the released version of my program on my release machine using pyinstaller v1.5.1.  This environment runs Python 2.7.1 dated 6/16/2011 and installed in /System/Library/Frameworks/Python.framework/Versions/Current.  IOW, the standard Apple version of Python that shipped with OS X 10.7 (Lion).  This version expects Tcl/Tk v8.5.9, which is loaded from /System/Frameworks/Tcl.framework... and /System/Frameworks/Tk.framework....  

2.  Back on my development machine, I have Python 2.7.2 dated 11/19/2011, which was installed using HomeBrew in /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/Current.   This version expects Tcl/Tk v8.5.11, which are in /Library/Frameworks/Tk.framework/Versions/8.5/Tk and /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl.

On my development machine, using pyinstaller-1.5.1 and running in 32-bit mode:

3. Pyinstaller-1.5.1 configure.py outputs:

  I: Adding Tcl dependency of _tkinter.so

  I: Analyzing /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so  

  I: Adding Tk dependency of _tkinter.so

4. The config.data file contains:

  TCL_dirname': 'Tcl.framework',

 'TCL_root': '/System/Library/Frameworks/Tcl.framework/Versions/Current',

 'TK_dirname': 'Tk.framework',

 'TK_root': '/System/Library/Frameworks/Tk.framework/Versions/Current', 

5. Build.py outputs:

  I: Analyzing /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so 

  I: Adding Tcl dependency of _tkinter.so

  I: Adding Tk dependency of _tkinter.so

When I run the resulting build, I get:

  /var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T//_MEIq6WLc4/_MEI/Tk.framework/Resources/Scripts/tk.tcl: version conflict for package "Tk": have 8.5.11, need exactly 8.5.9

Questions: 

• Is it better to resolve this part of the problem using pyinstaller v1.5.1, or should I ignore that and concentrate on more recent builds?
• Why does pyinstaller insist on going to /system/library/frameworks... (the apple build) when the correct files should come from /library/frameworks (user build)?
• Why doesn't changing the entries in config.dat affect this problem?  If I do that, when I run the program I still get the version conflict error.

[Hartmut Goebel]

Am 17.03.2012 00:34, schrieb Lynn Oliver:

• Is it better to resolve this part of the problem using pyinstaller v1.5.1, or should I ignore that and concentrate on more recent builds?

Please try to solve it in the current development version..

• Why doesn't changing the entries in config.dat affect this problem?  If I do that, when I run the program I still get the version conflict error.

In the current development version, config.dat not used any more.

[Martin Zibricky]

Lynn Oliver píše v Pá 16. 03. 2012 v 16:34 -0700
> * Why does pyinstaller insist on going

> to /system/library/frameworks... (the apple build) when the
> correct files should come from /library/frameworks (user
> build)?

Probably because the frozen executable can't load included Tcl and Tk
binaries and is thus looking for files in system location.

Could you put together a minimum example I could test?

How could I recreate your homebrew environment for testing?

[Lynn Oliver]

I just spent a week setting up a build environment on a clean install of OS X 10.7.3. My goal was to do a consistent install that avoids the use of package managers like MacPorts and HomeBrew, since they are suspected of causing issues with pyinstaller. There are now Lion-compatible binary installs available for the basic stuff: python 2.7.2, numpy 1.6.1, scipy 0.10.1, and matplotlib 1.1.0.

That's a huge improvement over what I struggled through back when Lion was still in beta. As a new installation, the first version of Xcode installed was the current one, 4.3.1 which presents some twists. Support for gcc-4.2 has been dropped, and Xcode is now packaged as an app instead of installing as /Developer/bin.

Libsamplerate 0.1.8 had to be built from source, but didn't cause any issues; pyinstaller needed altgraph-0.9 and modulegraph 0.9, which both built from source without issues. Libsndfile was a nightmare. Everything else together required just a few, but libsndfile has a long list of dependencies and requires a lot of specific tools that aren't found on OS X. Builds are not tested at all on OS X, so a successful build depends on making OS X look like a Unix system.

In the end I couldn't get it to work, and the developer couldn't help because he doesn't use OS X. I ended up using MacPorts to install libsndfile and portmidi, and pip to install scikits.samplerate and scikits.audiolab. Pyportmidi installed using the standard python setup.py install.

At least python and Tcl/Tk are installed in Library/Frameworks as pyinstaller seems to expect. However, when I run pyinstaller I still get exactly the same error. I'll start working my way through the build shortly.

Lynn

[Giovanni Bajo]

Il giorno 14/mar/2012, alle ore 23:38, Lynn Oliver ha scritto:

I had been building with '-F -w' options, so I removed the options and built again.  Looking in the dist folder, I see that Tcl and tk are already there, as I mentioned above.  I ran otools on the copy of _tkinter.so there, and got:

@executable_path/Tcl (compatibility version 8.5.0, current version 8.5.11)

@executable_path/Tk (compatibility version 8.5.0, current version 8.5.11)

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

When I execute ..dist/appname.app/Contents/MacOS/appname I get:

ImportError: dlopen(/var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIigFuUi/_tkinter.so, 2): Library not loaded: @executable_path/Tcl

  Referenced from: /var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIigFuUi/_tkinter.so

  Reason: image not found

This part baffles me.

You say that you were building with default build options, which makes a one-dir deployment. If it's a one-dire deployment, it should not create a temporary directory in /var/folders.

-- 

Giovanni Bajo   ::  ra...@develer.com
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it

[Lynn Oliver]

Here is a minimum program that fails.  It's just instantiates the Tkinter object and enters the processing loop.

[Hartmut Goebel]

Am 26.03.2012 20:40, schrieb Lynn Oliver:

Here are the files created in the TK_error/dist/TK_error folder:

Tcl/Tk is missing here at all. Your log both say: ERROR: could not find TCL/TK  So you need to find you why TK is not found.

Try running pyinstaller under the debugger and debug hook-_tkinter.py:

python -m pdb pyinstaller.py ...
b PyInstaller/hooks/hook-_tkinter.py:81
c

[Lynn Oliver]

Tcl/Tk is missing here at all. Your log both say: ERROR: could not find TCL/TK  

Yes, I know.  You asked me to create a simple example that reproduces the error.  That was it.

So you need to find you why TK is not found.

Look at my email from March 14th.  TK is not found because this code:

def find_tk_darwin(binaries):

    pattern = re.compile(r'_tkinter')

    for nm, fnm in binaries:

        mo = pattern.match(nm)

        if not mo:

            continue

        TCL_root = "/System/Library/Frameworks/Tcl.framework/Versions/Current"

        TK_root = "/System/Library/Frameworks/Tk.framework/Versions/Current"

        return TCL_root, TK_root

It is called with binaries equal to:

[('Tk', '/Library/Frameworks/Tk.framework/Versions/8.5/Tk'), ('Tcl', '/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl')]

It will always exit with TCL_root = TK_root = None, thus generating the TK not found error.  

I've opened a ticket for this issue.

-------------------------------------

Bypassing that issue so that the build can proceed, I get a different error on my two different build environments. 

For machine #1:

distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /Users/lynn/Documents/python/axeomatic2/pyinstaller/axeomatic/dist/axeomatic/lib/python2.7/config/Makefile (No such file or directory)

On machine #1, the python executable  /usr/local/bin/python links to /usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/bin/python

I understand this is likely to be a problem for Pyinstaller, which is why I built machine #2.

For machine #2:

ImportError: dlopen(/Users/Lynn/Documents/axeomatic2/pyinstaller/axeomatic/dist/axeomatic/_tkinter.so, 2): Library not loaded: @executable_path/Tcl

  Referenced from: /Users/Lynn/Documents/axeomatic2/pyinstaller/axeomatic/dist/axeomatic/_tkinter.so

  Reason: image not found

I get the same error in 64-bit and 32-bit mode.  What is "_tkinter.so, 2"? 

[Lynn Oliver]

I tend to get a bit wordy, so this may have been overlooked.  Can anyone give a tip as to what this relates to?

[Martin Zibricky]

Lynn Oliver píše v St 28. 03. 2012 v 22:40 -0700:

> ImportError:
> dlopen(/Users/Lynn/Documents/axeomatic2/pyinstaller/axeomatic/dist/axeomatic/_tkinter.so, 2): Library not loaded: @executable_path/Tcl Referenced from: /Users/Lynn/Documents/axeomatic2/pyinstaller/axeomatic/dist/axeomatic/_tkinter.so Reason: image not found

this means 'Tcl' file can't be found in the same directory as
_tkinter.so is.

Or another cause is mismatch in architectures - _tkinter.so is 32bit and
Tcl is 64bit or vice versa.

[Lynn Oliver]

I'm lost here.  I modified hook-_tikinter.py for debug purposes so that it returns what I think are the proper paths for Tcl and Tk.  It is called with binaries equal to:

[('Tk', '/Library/Frameworks/Tk.framework/Versions/8.5/Tk'), ('Tcl', '/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl')]

And it returns:

TCL_root

'/Library/Frameworks/Tcl.framework/Versions/8.5'

TK_root

'/Library/Frameworks/Tk.framework/Versions/8.5'

These are the correct folders for Tcl and Tk.

Next I see the function collect_tkfiles return what appears to be lists of every file in those two directories, as tcltree and tktree

Then I see analyze_r add ('_tkinter','Tkinter') to a list of names.  Nothing ever gets added to the list for Tcl and Tk.

Beyond that I don't know what to look at to see why the images for Tcl and Tk are not being added.

Any chance I could get some help figuring this out?

[Lynn Oliver]

Once again I started from scratch with a simple program and added imports until it broke the pyinstaller build.  The first import to cause an issue was scikits.samplerate, which is not listed as supported and is not found when searching the active tickets.

No complaints from the build, but when I run the executable I get:

File "/Users/lynn/Documents/python/axeomatic2/pyinstaller/testbuild/build/pyi.darwin/testbuild/out03-PYZ.pyz/distutils.sysconfig", line 370, in _init_posix

distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /Users/lynn/Documents/python/axeomatic2/pyinstaller/testbuild/dist/testbuild/lib/python2.7/config/Makefile (No such file or directory)

I have no idea why pyinstaller thinks there would be a lib/python2.7/config/Makefile in the dist directory..  Running python in verbose mode gives a bunch of successful imports followed by the exact same error.  It appears that none of the scikits.samplerate imports occur before the error.

Looking at the included hook files, other than the one for _tkinter they are all quite simple and basically deal with hidden imports.  I wouldn't be surprised if there are hidden imports involved here, but when I simply run python -v and do the samplerate import, I get 312 lines of stuff but nothing about a makefile.

Just to make things more interesting, I still get the Tcl/Tk errors if I try to build a onefile executable, so I'm avoiding that by using a patched hook-_tkinter.py file and not using the onefile option.

Given that I've spent way too much time on this, I have to take a step back and ask...  Is this beyond the scope of what a typical user can expect to get pyinstaller to do?

[Martin Zibricky]

Hi Lynn,

This is caused by a recent change in pyinstaller to set PYTHONHOME to
the directory with frozen application. This change should make frozen
executables fully independent on any python installation on given OS.

However, on Mac OS X this causes some side effects with distutils and
probably other modules.

I'm working on a fix for this. You could expect the fix in a few days.

Lynn Oliver píše v So 31. 03. 2012 v 20:21 -0700:

[Martin Zibricky]

Hi Lynn,

please try it again. It should be now fixed.

Lynn Oliver píše v So 31. 03. 2012 v 20:21 -0700:

[Lynn Oliver]

Hi Martin,

I rewrote my program to remove dependencies on SciKits.audiolab and SciKits.samplerate. If I run pyinstaller on that version in onedir mode, it actually builds and runs. Major progress, thanks! ( I do still have to change hook-_tkinter.py to insert the correct paths for Tcl/Tk.)

If I build in onefile mode, I get the following runtime error:

ImportError: dlopen(/var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIyI7ve3/_tkinter.so, 2): Library not loaded: @executable_path/Tcl
Referenced from: /var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIyI7ve3/_tkinter.so
Reason: image not found

What can cause it to fail in onefile mode but not onedir mode?

[Lynn Oliver]

Apparently quite a lot gets left out of the onefile build, as the package it creates is 33 MB, while the folder created by onefile mode is 89 MB.

Begin forwarded message:

[Martin Zibricky]

Lynn Oliver píše v Po 02. 04. 2012 v 16:03 -0700:

> ImportError:
> dlopen(/var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIyI7ve3/_tkinter.so, 2): Library not loaded: @executable_path/Tcl
> Referenced
> from: /var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIyI7ve3/_tkinter.so
> Reason: image not found
>
> What can cause it to fail in onefile mode but not onedir mode?

Could you compare the content of directory
like /var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIyI7ve3/ with
the onedir mode?

[Lynn Oliver]

How do I go about doing that? In onedir mode there are 139 files present; ArchiveViewer.py gives 13815 lines of output from onefile mode.

[Lynn Oliver]

Not sure if this is what you wanted, but I wrote a script to walk the onedir folder (appname/dist/appname) and look for any entries that did not exist in the output from ArchiveViewer run on the onefile file.

All the files in the onedir tree that were listed in the ArchiveViewer output. Well, except for five copies of '.DS_Store not found', which is a little odd on OS X.

[Martin Zibricky]

Lynn Oliver píše v Út 03. 04. 2012 v 14:53 -0700:

In your app you need to print 'sys._meipass' in console and
use function 'time.sleep()' keep your app running and to prevent
pyinstaller removing that temporary directory.

[Martin Zibricky]

Lynn Oliver píše v Po 02. 04. 2012 v 16:03 -0700:

> If I build in onefile mode, I get the following runtime error:
>
> ImportError:
> dlopen(/var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIyI7ve3/_tkinter.so, 2): Library not loaded: @executable_path/Tcl
> Referenced
> from: /var/folders/qq/h5gj3f3s0rx41lhd7h0lt2hm0000gn/T/_MEIyI7ve3/_tkinter.so
> Reason: image not found
>
> What can cause it to fail in onefile mode but not onedir mode?

Hi Oliver, I found out that we have a serious issue with onefile mode
(no matter what OS).

Current development version is not able import included Python
C-extension modules. Top-level modules works but not modules included in
submodules.

e.g: module 'time' is a C extension and on Linux it is file 'time.so'.
Frozen executable in onefile mode is able to find and import this
module.

But the following example won't work:
In wx library we have module 'wx._core_'. This is a C-extension module.
In default python installation it is file 'site-packages/wx/_core_.so'.
In frozen executable this module is renamed to 'wx._core_.so'. Modules
like this cannot be found and imported in onefile mode.

I'm trying to debug it. The broken file is ./PyInstaller/loader/iu.py.

I'm pretty sure the issue you are experiencing is related to this issue.

[Martin Zibricky]

Lynn Oliver píše v Po 02. 04. 2012 v 16:09 -0700:

> Apparently quite a lot gets left out of the onefile build, as the
> package it creates is 33 MB, while the folder created by onefile mode
> is 89 MB.

Please try latest development version if the fix there works for you.

Thanks.

[Lynn Oliver]

Same result with latest dev version of Pyinstaller.

[Martin Zibricky]

Lynn Oliver píše v Čt 05. 04. 2012 v 09:34 -0700:

> Same result with latest dev version of Pyinstaller.

Probably last think to try. Please try to do the following change and
let me know if it works for you:

diff --git a/PyInstaller/depend/dylib.py b/PyInstaller/depend/dylib.py
index 19ce8dd..ccccc06 100644
--- a/PyInstaller/depend/dylib.py
+++ b/PyInstaller/depend/dylib.py
@@ -202,7 +202,7 @@ def mac_set_relative_dylib_deps(libname):
if not util.in_system_path(pth):
# Use relative path to dependend dynamic libraries bases on
# location of the executable.
- return os.path.join('@executable_path',
os.path.basename(pth))
+ return os.path.join('@loader_path', os.path.basename(pth))

# Rewrite mach headers with @executable_path.
dll = MachO(libname)

[Lynn Oliver]

That seemed to do the trick. It now creates a an executable that runs. I'm not sure why the executable is so much smaller than the onedir, so I'll have to run it through some testing to see if everything works. It didn't pick up the matplotlibrc file, so I'll have to figure out if there is a way to get that loaded into the default directory.

Will this change eventually make it into the library? How about an update to hook-_tkinter.py?

Thanks again for the help...
Lynn

[Martin Zibricky]

Lynn Oliver píše v Pá 06. 04. 2012 v 00:57 -0700:

> That seemed to do the trick. It now creates a an executable that
> runs. I'm not sure why the executable is so much smaller than the
> onedir,

It is smaller becase in onefile mode all files are zipped.

> so I'll have to run it through some testing to see if everything
> works. It didn't pick up the matplotlibrc file, so I'll have to
> figure out if there is a way to get that loaded into the default
> directory.
>
> Will this change eventually make it into the library?

loader_path needs more testing. i think it breaks pyqt hooks and
qt_plugins loading. need to find out a workaround. maybe something else
is broken.

> How about an update to hook-_tkinter.py?

could you please sumarize the thing with tkinter?

[Lynn Oliver]

On Apr 6, 2012, at 1:29 AM, Martin Zibricky wrote:

>
> could you please sumarize the thing with tkinter?

hook-_tkinter.py contains the following function:

def find_tk_darwin(binaries):
pattern = re.compile(r'_tkinter')
for nm, fnm in binaries:
mo = pattern.match(nm)
if not mo:
continue
TCL_root = "/System/Library/Frameworks/Tcl.framework/Versions/Current"
TK_root = "/System/Library/Frameworks/Tk.framework/Versions/Current"
return TCL_root, TK_root

On my system it it called with binaries =

[('Tk', '/Library/Frameworks/Tk.framework/Versions/8.5/Tk'), ('Tcl', '/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl')]

The statement mo = pattern.match(nm) does not find a match, and since the last three statements are inside the for loop, they are not executed. I changed it to something like this:

def find_tk_darwin(binaries):

TCL_root = "/System/Library/Frameworks/Tcl.framework/Versions/Current"
TK_root = "/System/Library/Frameworks/Tk.framework/Versions/Current"

for nm, fnm in binaries:

if nm == 'Tk':
TK_root = fnm
elif nm == 'Tcl':
TCL_root = fnm
return TCL_root, TK_root

For reference, here are all of the standard Tcl/Tk install locations that I could find:

OS X 10.7:
/System/Library/Frameworks/Tcl.framework/Versions/Current
/System/Library/Frameworks/Tk.framework/Versions/Current

A user install from binaries goes to:
/Library/Frameworks/Tcl.framework/Versions/Current
/Library/Frameworks/Tk.framework/Versions/Current

The current SDK (4.2) which is now installed as an app package:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Tcl.framework/Versions/Current
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Tcl.framework/Versions/Current
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Tk.framework/Versions/Current
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Tk.framework/Versions/Current

SDK 4.1:
/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Tcl.framework/Versions/Current
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Tcl.framework/Versions/Current
/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Tk.framework/Versions/Current
/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Tk.framework/Versions/Current

[Martin Zibricky]

Lynn Oliver píše v Pá 06. 04. 2012 v 14:28 -0700:

> On my system it it called with binaries =
> [('Tk', '/Library/Frameworks/Tk.framework/Versions/8.5/Tk'), ('Tcl',
> '/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl')]

One idea: we could determine the TCL_root and TK_root just as dirname
from these binaries like:

for lib, fnm in binaries:
if lib == 'Tcl':
TCL_root = os.path.dirname(fnm)
if lib == 'Tk':
TK_root = os.path.dirname(fnm)

I think this might work in most cases.

[Lynn Oliver]

My program builds now on OS X, but unfortunately I need to release it on win32 and win64 as well.  Working on win32, I have my program running under the debugger.  When I try to build, using the developer version of pyinstaller from a couple of days ago, I get this (full output from build is at end of message):

INFO: Analyzing x:\axeomatic2\axeomatic.py

ERROR: lib not found: MSVCR90.dll dependency of C:\Python27\DLLs\_tkinter.pyd

...

INFO: Adding Microsoft.VC90.CRT to dependent assemblies of final executable

INFO: Searching for assembly x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww ...

INFO: Found manifest C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8

_x-ww_d08d0375.manifest

INFO: Searching for file msvcr90.dll

INFO: Found file C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375

\msvcr90.dll

INFO: Searching for file msvcp90.dll

INFO: Found file C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375

\msvcp90.dll

INFO: Searching for file msvcm90.dll

INFO: Found file C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375

\msvcm90.dll

Since it was found, does this mean I can ignore the error?

ERROR: lib not found: libgdk_pixbuf-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib

\backends\_backend_gdk.pyd

ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\ba

ckends\_backend_gdk.pyd

ERROR: lib not found: libgdk-win32-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\

backends\_gtkagg.pyd

ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\ba

ckends\_gtkagg.pyd

These are a bit of a mystery.  I'm using the Tkagg backend, so I'm not sure why these files are being analyzed.  The missing files are found in my Wing IDE installation (debugger), but that should be completely separate from this build.

Any suggestions as to how I might figure this out?

Complete Output:

INFO: wrote C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\axeomatic\axeomatic.s

pec

INFO: Testing for ability to set icons, version resources...

INFO: ... resource update available

INFO: UPX is not available.

INFO: checking Analysis

INFO: building because x:\axeomatic2\axeomatic.py changed

INFO: running Analysis out00-Analysis.toc

INFO: Analyzing C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\support\_pyi_boot

strap.py

INFO: Analyzing x:\axeomatic2\axeomatic.py

ERROR: lib not found: MSVCR90.dll dependency of C:\Python27\DLLs\_tkinter.pyd

INFO: checking Tree

INFO: checking Tree

INFO: Hidden import 'encodings' has been found otherwise

INFO: Adding Microsoft.VC90.CRT to dependent assemblies of final executable

INFO: Searching for assembly x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww ...

INFO: Found manifest C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8

_x-ww_d08d0375.manifest

INFO: Searching for file msvcr90.dll

INFO: Found file C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375

\msvcr90.dll

INFO: Searching for file msvcp90.dll

INFO: Found file C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375

\msvcp90.dll

INFO: Searching for file msvcm90.dll

INFO: Found file C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375

\msvcm90.dll

ERROR: lib not found: libgdk_pixbuf-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib

\backends\_backend_gdk.pyd

ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\ba

ckends\_backend_gdk.pyd

ERROR: lib not found: libgdk-win32-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\

backends\_gtkagg.pyd

ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\ba

ckends\_gtkagg.pyd

INFO: Adding Microsoft.Windows.Common-Controls to dependent assemblies of final executable

INFO: Warnings written to C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\axeomat

ic\build\pyi.win32\axeomatic\warnaxeomatic.txt

INFO: checking PYZ

INFO: building because toc changed

INFO: building PYZ out03-PYZ.toc

INFO: checking PKG

INFO: building because C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\axeomatic\

build\pyi.win32\axeomatic\out03-PYZ.pyz changed

INFO: building PKG out05-PKG.pkg

INFO: checking EXE

INFO: Removing file C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\axeomatic\dis

t\axeomatic.exe

INFO: rebuilding out04-EXE.toc because axeomatic.exe missing

INFO: building EXE from out04-EXE.toc

INFO: Appending archive to EXE C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\ax

eomatic\dist\axeomatic.exe

[Martin Zibricky]

Lynn Oliver píše v Ne 08. 04. 2012 v 13:18 -0700:

> Any suggestions as to how I might figure this out?

The binary windows bootloader is not up-to date (not recompiled). Do you
have visual studio on your windows box? Could you try to recompile
windows bootloader?

[Lynn Oliver]

I recompiled the win32 bootloader and reran pyinstaller. The same errors were reported.

[Martin Zibricky]

Lynn Oliver píše v Ne 08. 04. 2012 v 13:18 -0700:

> INFO: Analyzing x:\axeomatic2\axeomatic.py ERROR: lib not found:
> MSVCR90.dll dependency of C:\Python27\DLLs\_tkinter.pyd

What is the value of your PATH environment variable?

$ echo %PATH%

Another think is we should probably verify if pyinstaller ignores lower
and uppercase in dll file names:

MSVCR90.dll and msvcr90.dll should be the same file.

[Lynn Oliver]

echo %path%
C:\Program Files\Parallels\Parallels Tools\Applications;C:\Tcl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Python27;C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE

On Apr 10, 2012, at 11:42 AM, Martin Zibricky wrote:

> echo %PATH%

[Martin Zibricky]

Lynn Oliver píše v Ne 08. 04. 2012 v 13:18 -0700:

> INFO: Analyzing x:\axeomatic2\axeomatic.py ERROR: lib not found:
> MSVCR90.dll dependency of C:\Python27\DLLs\_tkinter.pyd

Could you try find 'msvcr90.dll' in your OS and put a copy of this file
named 'MSVCR90.dll' somewhere on your system PATH? (probably
c:\windows\system32)

[Lynn Oliver]

I put a copy in c:\windows\system32, although I left the name in lower case.  

That got rid of the msvcr90.dll error, but I still have the remaining ones:

ERROR: lib not found: libgdk_pixbuf-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib

\backends\_backend_gdk.pyd

ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\ba

ckends\_backend_gdk.pyd

ERROR: lib not found: libgdk-win32-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\

backends\_gtkagg.pyd

ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\ba

ckends\_gtkagg.pyd

[Martin Zibricky]

Lynn Oliver píše v Út 10. 04. 2012 v 13:14 -0700:

> I put a copy in c:\windows\system32, although I left the name in lower
> case.
>
> That got rid of the msvcr90.dll error, but I still have the remaining
> ones:

Otherwise it works as expected?

I think pyinstaller is trying to resolve dependencies of all available
matplotlib backends but not all dependencies are fulfilled.

I think if it otherwise works these errors could be ignored.

[Lynn Oliver]

No, it doesn't run.  If I run .../dist/appname.exe nothing seems to happen.  If I run .../dist/appname/appname.exe I get an import error: no module named multiarray. 

It looks like it was trying to import numpy when it failed; there is a module named numpy.core.multiarray.pyd in the .../dist/appname folder.  

I ran it again in verbose mode; I'll append the output just in case it can tell you something.

_MEIPASS2 is NULL

archivename is C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\axeomatic\dist\axe

omatic\axeomatic.exe

No need to extract files to run; setting extractionpath to homepath

Already in the child - running!

manifestpath: C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\axeomatic\dist\axeo

matic\axeomatic.exe.manifest

Activation context created

Activation context activated

C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\axeomatic\dist\axeomatic\python27

.dll

Manipulating evironment

PYTHONPATH=C:/Documents and Settings/Lynn/My Documents/aom2-local/pyinstaller/axeomatic/dist/axeomat

ic

PYTHONHOME=C:/Documents and Settings/Lynn/My Documents/aom2-local/pyinstaller/axeomatic/dist/axeomat

ic/

v

# installing zipimport hook

import zipimport # builtin

# installed zipimport hook

importing modules from CArchive

import marshal # builtin

extracted iu

import imp # builtin

import nt # builtin

extracted struct

import _struct # builtin

extracted archive

Installing import hooks

out03-PYZ.pyz

Running scripts

import win32api # dynamically loaded from C:/Documents and Settings/Lynn/My Documents/aom2-local/pyi

nstaller/axeomatic/dist/axeomatic\win32api.pyd

import zlib # builtin

import errno # builtin

import _weakref # builtin

import _codecs # builtin

import _sre # builtin

import strop # builtin

import _ctypes # dynamically loaded from C:\Documents and Settings\Lynn\My Documents\aom2-local\pyin

staller\axeomatic\dist\axeomatic\_ctypes.pyd

import _tkinter # dynamically loaded from C:\Documents and Settings\Lynn\My Documents\aom2-local\pyi

nstaller\axeomatic\dist\axeomatic\_tkinter.pyd

import _collections # builtin

import operator # builtin

import itertools # builtin

import _bisect # builtin

import _heapq # builtin

import thread # builtin

import cStringIO # builtin

import gc # builtin

import time # builtin

import msvcrt # builtin

import _subprocess # builtin

import array # builtin

Traceback (most recent call last):

  File "<string>", line 10, in <module>

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 432, in importHook

    mod = _self_doimport(nm, ctx, fqname)

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 526, in doimport

    exec co in mod.__dict__

  File "axeomatic\build\pyi.win32\axeomatic\out03-PYZ.pyz\FileConvert", line 4, in <module>

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 432, in importHook

    mod = _self_doimport(nm, ctx, fqname)

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 526, in doimport

    exec co in mod.__dict__

  File "axeomatic\build\pyi.win32\axeomatic\out03-PYZ.pyz\AxeConvert", line 7, in <module>

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 432, in importHook

    mod = _self_doimport(nm, ctx, fqname)

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 526, in doimport

    exec co in mod.__dict__

  File "axeomatic\build\pyi.win32\axeomatic\out03-PYZ.pyz\SysExWave", line 4, in <module>

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 432, in importHook

    mod = _self_doimport(nm, ctx, fqname)

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 526, in doimport

    exec co in mod.__dict__

  File "axeomatic\build\pyi.win32\axeomatic\out03-PYZ.pyz\myUtils", line 4, in <module>

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 432, in importHook

    mod = _self_doimport(nm, ctx, fqname)

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 526, in doimport

    exec co in mod.__dict__

  File "axeomatic\build\pyi.win32\axeomatic\out03-PYZ.pyz\numpy", line 137, in <module>

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 432, in importHook

    mod = _self_doimport(nm, ctx, fqname)

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 526, in doimport

    exec co in mod.__dict__

  File "axeomatic\build\pyi.win32\axeomatic\out03-PYZ.pyz\numpy.add_newdocs", line 9, in <module>

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 432, in importHook

    mod = _self_doimport(nm, ctx, fqname)

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 526, in doimport

    exec co in mod.__dict__

  File "axeomatic\build\pyi.win32\axeomatic\out03-PYZ.pyz\numpy.lib", line 4, in <module>

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 432, in importHook

    mod = _self_doimport(nm, ctx, fqname)

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 526, in doimport

    exec co in mod.__dict__

  File "axeomatic\build\pyi.win32\axeomatic\out03-PYZ.pyz\numpy.lib.type_check", line 8, in <module>

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 432, in importHook

    mod = _self_doimport(nm, ctx, fqname)

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 526, in doimport

    exec co in mod.__dict__

  File "axeomatic\build\pyi.win32\axeomatic\out03-PYZ.pyz\numpy.core", line 5, in <module>

  File "C:\Documents and Settings\Lynn\My Documents\aom2-local\pyinstaller\PyInstaller\loader\iu.py"

, line 455, in importHook

    raise ImportError("No module named %s" % fqname)

ImportError: No module named multiarray

RC: -1 from axeomatic

OK.

Deactivating activation context

Releasing activation context

Done

[Lynn Oliver]

I went back and tried v1.5.1, and both i386 and x64 versions build fine. I'll try the dev build again whenever you think some of the issues have been fixed.

Lynn

[Martin Zibricky]

Lynn Oliver píše v Ne 15. 04. 2012 v 15:30 -0700:

Could you please try latest development version?

Some issues have been fixed recently and I would like to fix the issues
you are experiencing.

[Lynn Oliver]

I cloned the current version of pyinstaller on a Win7-64 machine and a WinXP-32 machine. Both machines build from the same source tree.

On Win7-64 the program builds and runs. I did get one error message and a bunch of CantPackExceptions.

ERROR: lib not found: gdiplus.dll dependency of C:\Python27\lib\site-packages\wx\wxmsw28uh_core_vc.dll

upx: C:\Users\Lynn Oliver\AppData\Roaming\pyinstaller\bincache01\calc_lwork.pyd: CantPackException: can't pack new-exe
upx: C:\Users\Lynn Oliver\AppData\Roaming\pyinstaller\bincache01\calc_lwork.pyd: CantPackException: can't pack new-exe
upx: C:\Users\Lynn Oliver\AppData\Roaming\pyinstaller\bincache01\flapack.pyd: CantPackException: can't pack new-exe
etc.

On WinXP-32 the program builds and runs. I got the following error messages relating to a matplotlib backend that I'm not using, and a couple of upx messages.

ERROR: lib not found: libgdk_pixbuf-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\backends\_backend_gdk.pyd

ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\backends\_backend_gdk.pyd

ERROR: lib not found: libgdk-win32-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\backends\_gtkagg.pyd
ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27\lib\site-packages\matplotlib\backends\_gtkagg.pyd

upx: C:\Documents and Settings\Lynn\Application Data\pyinstaller\bincache01\_windowing.pyd: NotCompressibleException
upx: C:\Documents and Settings\Lynn\Application Data\pyinstaller\bincache01\msvcm90.dll: CantPackException: .NET files (win32/.net) are not yet supported

[Martin Zibricky]

Lynn Oliver píše v Út 17. 04. 2012 v 16:20 -0700:

>
> On WinXP-32 the program builds and runs. I got the following error
> messages relating to a matplotlib backend that I'm not using, and a
> couple of upx messages.
>
> ERROR: lib not found: libgdk_pixbuf-2.0-0.dll dependency of C:
> \Python27\lib\site-packages\matplotlib\backends\_backend_gdk.pyd
> ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27
> \lib\site-packages\matplotlib\backends\_backend_gdk.pyd
> ERROR: lib not found: libgdk-win32-2.0-0.dll dependency of C:\Python27
> \lib\site-packages\matplotlib\backends\_gtkagg.pyd
> ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27
> \lib\site-packages\matplotlib\backends\_gtkagg.pyd

Do you have any suggestions how these "errors" could be eliminated?

My idea is that pyinstaller tries import all backends and include in
hidden imports only those available.

[Martin Zibricky]

Lynn Oliver píše v Út 17. 04. 2012 v 16:20 -0700:
>

> ERROR: lib not found: libgdk_pixbuf-2.0-0.dll dependency of C:
> \Python27\lib\site-packages\matplotlib\backends\_backend_gdk.pyd
> ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27
> \lib\site-packages\matplotlib\backends\_backend_gdk.pyd
> ERROR: lib not found: libgdk-win32-2.0-0.dll dependency of C:\Python27
> \lib\site-packages\matplotlib\backends\_gtkagg.pyd
> ERROR: lib not found: libgobject-2.0-0.dll dependency of C:\Python27
> \lib\site-packages\matplotlib\backends\_gtkagg.pyd

These errors are now gone.

[Martin Zibricky]

Lynn Oliver píše v Út 17. 04. 2012 v 16:20 -0700:

> On Win7-64 the program builds and runs. I did get one error message
> and a bunch of CantPackExceptions.
>
> ERROR: lib not found: gdiplus.dll dependency of C:\Python27\lib
> \site-packages\wx\wxmsw28uh_core_vc.dll

This issue seems really tricky:
- gdiplus.dll is not present on 64bit win7 in C:\Windows\SysWOW64.
- there are several files GdiPlus.dll in C:\Windows\winsxs
- The issue is with wxpython binary because it does not specify assembly
manifest with dependency on GdiPlus.
- without the manifest in wx binaries pyinstaller can't find GdiPlus as
a dependency.

I'm not sure how this should be fixed. Probably pyinstaller would have
to look for dlls in assembly dirs (c:\windows\winsxs) without manifest
files.

[Martin Zibricky]

Hi Lynn,

could you please test latest dev version with the fix for @loader_path?
I just commited the proper fix for that.

Could you please summarize how hook-_tkinter.py should be fixed?

Thanks,
Martin

Lynn Oliver píše v Pá 06. 04. 2012 v 00:57 -0700:

[Lynn Oliver]

Using the latest dev version as-is, I get "Can't find a usable tk.tcl in the following directories...."

Replacing hook-_tkinter.py with the patched version, it works.

The patch to hook-_tkinter.py replaces:

def find_tk_darwin(binaries):
pattern = re.compile(r'_tkinter')
for nm, fnm in binaries:
mo = pattern.match(nm)
if not mo:
continue

TCL_root = "/Library/Frameworks/Tcl.framework/Versions/Current"
TK_root = "/Library/Frameworks/Tk.framework/Versions/Current"
return TCL_root, TK_root

with

def find_tk_darwin(binaries):
TCL_root = "/Library/Frameworks/Tcl.framework/Versions/Current"
TK_root = "/Library/Frameworks/Tk.framework/Versions/Current"
return TCL_root, TK_root

If you look back at the ticket, I believe I added everything there regarding install locations for Tcl/Tk.

Lynn

[Martin Zibricky]

Lynn Oliver píše v Pá 04. 05. 2012 v 11:12 -0700:

> Using the latest dev version as-is, I get "Can't find a usable tk.tcl
> in the following directories...."
>
> Replacing hook-_tkinter.py with the patched version, it works.
>
> The patch to hook-_tkinter.py replaces:
>
> def find_tk_darwin(binaries):
> pattern = re.compile(r'_tkinter')
> for nm, fnm in binaries:
> mo = pattern.match(nm)
> if not mo:
> continue
> TCL_root = "/Library/Frameworks/Tcl.framework/Versions/Current"
> TK_root = "/Library/Frameworks/Tk.framework/Versions/Current"
> return TCL_root, TK_root
>
> with
>
> def find_tk_darwin(binaries):
> TCL_root = "/Library/Frameworks/Tcl.framework/Versions/Current"
> TK_root = "/Library/Frameworks/Tk.framework/Versions/Current"
> return TCL_root, TK_root
>
> If you look back at the ticket, I believe I added everything there
> regarding install locations for Tcl/Tk.

Thanks.

We need to fix find_tk_darwin for Tcl/Tk when installed as framework and
when installed as non-framework (in macports it is installed as
non-framework).

I will ask you again for testing when it is fixed.

[Martin Zibricky]

Hi Lynn,

could you please test latest dev version?

There is now committed a fix for the tcl/tk hook to work on Mac
properly.

Let me know if it still works for you.

Thanks in advance.

Martin.

Lynn Oliver píše v Pá 04. 05. 2012 v 11:12 -0700:

[Lynn Oliver]

I confirmed that it works on my system. Does this mean that 2.0 is getting close?

Lynn

[Martin Zibricky]

Lynn Oliver píše v St 09. 05. 2012 v 08:28 -0700:

> I confirmed that it works on my system.

Thanks.

> Does this mean that 2.0 is getting close?

It is another step closer to 2.0. But still need to go through other
open tickets in the 2.0 milestone.

[Martin Zibricky]

marnix...@hotmail.com píše v So 19. 01. 2013 v 00:06 -0800:
> I have now idea what to do next. Do any of you have any other ideas?

Trying the latest development version.

[marnix...@hotmail.com]

Good idea, of course.
I installed the latest dev version, but unfortunately I'm still getting exactly the same error.
Does anyone have a clue what I could try next?

[Martin Zibricky]

marnix...@hotmail.com píše v Út 22. 01. 2013 v 23:22 -0800:

> Good idea, of course.
> I installed the latest dev version, but unfortunately I'm still
> getting exactly the same error.
> Does anyone have a clue what I could try next?

then tell us more info about your environment and how to reproduce your
issue.

[marnix...@hotmail.com]

Environment is Mac OS X 10.8.2 Mountain Lion.
Python version is 2.7.3.
Tcl/Tk version is 8.5.9.
Xcode version is 4.5.2.
What further info would be useful?

[Martin Zibricky]

marnix...@hotmail.com píše v Po 28. 01. 2013 v 10:59 -0800:

How did you install python and tcl/tk?

[Martin Zibricky]

marnix...@hotmail.com píše v Po 28. 01. 2013 v 10:59 -0800:

Does the pyinstaller tcl/tk test case work for you?

cd buildtests
python ./runtests.py -v interactive/test_tkinter.py

[marnix...@hotmail.com]

No, it doesn't. It gives the same error:

Traceback (most recent call last):

  File "<string>", line 3, in <module>
  File "/Users/marnixmedema/pyinstaller-pyinstaller-c6d550c/PyInstaller/loader/pyi_importers.py", line 247, in load_module
    exec(bytecode, module.__dict__)
  File "/Users/marnixmedema/pyinstaller-pyinstaller-c6d550c/buildtests/interactive/build/pyi.darwin/test_tkinter/out00-PYZ.pyz/Tkinter", line 39, in <module>
  File "/Users/marnixmedema/pyinstaller-pyinstaller-c6d550c/PyInstaller/loader/pyi_importers.py", line 308, in load_module
    module = imp.load_module(fullname, fp, filename, self._c_ext_tuple)
ImportError: dlopen(/Users/marnixmedema/pyinstaller-pyinstaller-c6d550c/buildtests/interactive/dist/test_tkinter/_tkinter.so, 2): Library not loaded: @loader_path/Tcl
  Referenced from: /Users/marnixmedema/pyinstaller-pyinstaller-c6d550c/buildtests/interactive/dist/test_tkinter/_tkinter.so
  Reason: image not found

FAIL

======================================================================
FAIL: test_tkinter (__main__.GenericTestCase)
----------------------------------------------------------------------

Traceback (most recent call last):

  File "runtests.py", line 460, in _generic_test_function
    msg='Running exe of %s failed.' % self.test_name)
AssertionError: False is not True : Running exe of interactive/test_tkinter failed.

----------------------------------------------------------------------
Ran 1 test in 19.378s

[Martin Zibricky]

marnix...@hotmail.com píše v Čt 31. 01. 2013 v 10:02 -0800:

> No, it doesn't. It gives the same error:

Then let's get back to the way how you installed python and tcl/tk.

Did you compile it yourself or do you use just python bundled with OS X?

[marnix...@hotmail.com]

First, I used the Python bundled with OS X. At this time, PyInstaller worked without problems.
Later, I needed to get another Python library (libxml / pyquery) to work, and in order to do so I re-installed Python using http://python.org/ftp/python/2.7.3/python-2.7.3-macosx10.6.dmg . I also installed the new version of Xcode (upgrade from 2 to 4) and installed a number of Python packages/libs using pip/macports/homebrew. Finally, I got the other Python library to work, but then I discovered that PyInstaller no longer works when trying to compile Tcl/Tk programs...

[Martin Zibricky]

marnix...@hotmail.com píše v Ne 03. 02. 2013 v 23:31 -0800:

> Python using
> http://python.org/ftp/python/2.7.3/python-2.7.3-macosx10.6.dmg . I
> also installed the new version of Xcode (upgrade from 2 to 4) and
> installed a number of Python packages/libs using
> pip/macports/homebrew. Finally, I got the other Python library to
> work, but then I discovered that PyInstaller no longer works when
> trying to compile Tcl/Tk programs...

And now the python version that is failing is which one?
python.org/macports/homebrew?

[marnix...@hotmail.com]

I wasn't entirely sure, so I just reinstalled Python from Python.org, and also re-installed Tcl/Tk, using the version recommended by python.org (8.5.13).
Now, the test script runs without problems and reports success. Unfortunately, when I compile my program I do still get the same error...

[marnix...@hotmail.com]

Ah... I just had to remove the old .pyc files and then it worked! Could it have been due to some incompatibility with Tcl/Tk 8.6, which was installed before?

[Martin Zibricky]

marnix...@hotmail.com píše v St 06. 02. 2013 v 10:00 -0800:

>
> Ah... I just had to remove the old .pyc files and then it worked!
> Could it have been due to some incompatibility with Tcl/Tk 8.6, which
> was installed before?

What files you had to remove?

[marnix...@hotmail.com]

I removed the compiled .pyc files of all .py files that would be imported into the program.
But I guess that only the .pyc files of .py files involving Tcl/Tk really matter...

[marnix...@hotmail.com]

I thought all this was a happy ending, but unfortunately it's not.
It seems that the versions that I built with PyInstaller before making these changes work fine on other people's systems, but the latest version gives some Tcl/Tk error outside my own system:

/Users/KC/Documents/Multigeneblast_1/mgb_gui ; exit;

KCs-MacBook-Air:~ KC$ /Users/KC/Documents/Multigeneblast_1/mgb_gui ; exit;

Traceback (most recent call last):

  File "<string>", line 810, in <module>

  File "<string>", line 749, in maingui

  File "/Users/marnixmedema/pyinstaller-pyinstaller-c6d550c/mgb_gui/build/pyi.darwin/mgb_gui/out00-PYZ.pyz/Tkinter", line 1685, in __init__

_tkinter.TclError: Can't find a usable init.tcl in the following directories:

    /var/folders/hm/fpkv7y2n6kldr6p32nt7f6kw0000gn/T/_MEIDLtgU2/_MEI/tcl /var/folders/hm/fpkv7y2n6kldr6p32nt7f6kw0000gn/T/_MEIDLtgU2/_MEI/tcl8.5 /Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts /Users/KC/Documents/lib/tcl8.5 /Users/KC/lib/tcl8.5 /Users/KC/Documents/library /Users/KC/library /Users/KC/tcl8.5.13/library /Users/tcl8.5.13/library

 

/var/folders/hm/fpkv7y2n6kldr6p32nt7f6kw0000gn/T/_MEIDLtgU2/_MEI/tcl/init.tcl: can't find package activestate::teapot::link

can't find package activestate::teapot::link

    while executing

"package require activestate::teapot::link"

    invoked from within

"if {![interp issafe] && ![catch {package require platform}]} {

            package require activestate::teapot::link

            ::activestate::teapot::link::setup

..."

    (file "/var/folders/hm/fpkv7y2n6kldr6p32nt7f6kw0000gn/T/_MEIDLtgU2/_MEI/tcl/init.tcl" line 876)

    invoked from within

"source /var/folders/hm/fpkv7y2n6kldr6p32nt7f6kw0000gn/T/_MEIDLtgU2/_MEI/tcl/init.tcl"

    ("uplevel" body line 1)

    invoked from within

"uplevel #0 [list source $tclfile]"

 

 

This probably means that Tcl wasn't installed properly.

 

logout

Any ideas on how I could prevent this?


 

[marnix...@hotmail.com]

Ah... it seems that the other systems need to have exactly the same version of Tcl/Tk installed.
When my users install Tcl/Tk 8.5.13, it works fine on their systems.
Is there a way to circumvent this?

[Hartmut Goebel]

So this is a clear sign that not all required libraries are bundled :-(

--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP

Goebel Consult
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/2012-02-bring-your-own-life-glosse
Blog: http://www.goebel-consult.de/blog/20060920

Goebel Consult ist Mitglied bei http://www.7-it.de/

[marnix...@hotmail.com]

On Saturday, February 9, 2013 12:48:37 PM UTC+1, Hartmut Goebel wrote:

So this is a clear sign that not all required libraries are bundled :-(

That makes sense. Does anybody have an idea what can be done about this?
I'm happy to help in any way I can, but I am not too familiar with the inner workings of PyInstaller...

[Martin Zibricky]

Where are placed the binaries of tcl/tk? Is anything in /usr/lib?

Pyinstaller ignores everything from /usr/lib.

Look at file ./PyInstaller/depend/dylib.py how the exclude list
constructed.

On osx we use macholib to decide if a library is a system library or
not.

marnix...@hotmail.com píše v So 09. 02. 2013 v 04:04 -0800:

[marnix...@hotmail.com]

I noticed that when on the command-line I input 'tclsh' and then 'info patchlevel', it says that the Tcl/Tk version is 8.5.9. This is the native pre-installed Apple Tk version. However, the version that I installed later to make PyInstaller work again is 8.5.13.
Could it be that the program packages Apple 8.5.9 Tk but in fact refers to ActiveTcl 8.5.13? (See http://www.python.org/getit/mac/tcltk/#apple-8-5-9)

[marnix...@hotmail.com]

Ah... good idea. I will try if I can manually remove it from the exclude list... :)

[marnix...@hotmail.com]

On Saturday, February 9, 2013 2:15:08 PM UTC+1, marnix...@hotmail.com wrote:

Ah... good idea. I will try if I can manually remove it from the exclude list... :)

The paths that are passed through the lib checking in dylib.py are /Library/Frameworks/Tk.framework/Versions/8.5/Tk and /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl . Both of these return False for util.in_system_path(libname), so they should not be in the exclude list, right?

Based on the error above, could activestate:teapot be the problem instead?
Maybe I can try to uninstall ActiveTcl and build Tcl/Tk from source instead, so it shouldn't rely on teapot...

[marnix...@hotmail.com]

I just found out that the Apple pre-installed Tcl/Tk versions are in /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl and /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk
When I uninstall ActiveTcl again, at first it doesn't work (I get back to my original situation).
But then when i simply modify the MacExcludeList() class as follows, the executable works fine!

   class MacExcludeList(object):
        def search(self, libname):
             if "/Tcl" in libname or "/Tk" in libname:
                return False
            return util.in_system_path(libname)

So it seems it needs to package the Tcl/Tk that is pre-installed on Mac OS X, but the original MacExcludeList object will prevent this by default...
Any ideas why this is happening?

[Martin Zibricky]

marnix...@hotmail.com píše v So 09. 02. 2013 v 06:25 -0800:

> class MacExcludeList(object):
> def search(self, libname):
> if "/Tcl" in libname or "/Tk" in libname:
> return False
> return util.in_system_path(libname)
>
>
> So it seems it needs to package the Tcl/Tk that is pre-installed on
> Mac OS X, but the original MacExcludeList object will prevent this by
> default...
> Any ideas why this is happening?

The assumption is that stuff in /System or in /usr/lib is supposed to be
stable and available on every osx. However, that seems not working
everywhere.

We would have to define list of libraries that should be handled - Tcl
and Tk and some pyside libraries are first candidates.

[marnix...@hotmail.com]

That sounds like a useful update... :)

[marnix...@hotmail.com]

Bad news. Although it was working on my own system when removing Tcl and Tk from the exclude list, my users now get the following.
Do you expect there are many more libraries that need to be included before it works on other systems?

[marnix...@hotmail.com]

Even removing the CoreText lib from the exception list doesn't help... Same error... :(

[marnix...@hotmail.com]

(or maybe I had to remove the old build directories first...)

[marnix...@hotmail.com]

No, that appeared not to work either. So I guess I will have to ask people to download ActiveTcl.
If I have ActiveTcl installed, it generates an executable that works on other systems with ActiveTcl installed.
Or does anybody have any other idea to make it work with the regular Tcl/Tk?