PyInstaller withTCL/TK

[akineko]

Hello everyone,

I have been using Gordon McMillan's Installer and PyInstaller for
years to provide Python scripts under Windows. Now I'm experimenting
it under Unix (Linux / Solaris).

When I run Configure.py, I got the following message:

I: Finding TCL/TK...
I: could not find TCL/TK <<<---

As my Python scripts use TkInter, this is something I need to resolve.
First I thought that my environment was not right. So, I tried it both
under Linux and under Solaris. The Configure script failed to find the
TCL/TK in both platforms.

I tried to decipher the Configure.py script.
It seems using ldd <dynamic link library> to obtain the path to
libtcl.so.
The problem is that no 'ExtensionModule' (with .so) has references to
the tcl library.

I checked the Gordon McMillan's original code and found the same.
Maybe the scheme worked with earlier version but I couldn't see any
reason it would work under current Python + Tcl/Tk software.

I also checked the latest code in the CVS tree but the code remains
the same.

My questions are:
(1) Has anyone used PyInstaller to package Tkinter programs under Unix
(solaris / Linux)?
(2) What is the best way to work around this problem? (Any
suggestions?)

Thank you for your attention.

Best regards,
Aki Niimura

[Simosito]

Hi,
I'm using PyInstaller on Linux and I have no problems: Configure.py
finds everything.

Have you installed libc6-dev, python-dev, zliblg-dev?

Does PyInstaller works with non-tk scripts?

I've installed the Idle package too, before I ran Configure.py

Maybe you should try to install via something like a package manager
the IDLE.

Maybe that silly thing can solve your problem...

I hope you'll solve this problem of yours,
Simone Ramacci

On 25 Giu, 10:20, akineko <akin...@gmail.com> wrote:
> Hello everyone,
>
> I have been using Gordon McMillan's Installer and PyInstaller for
> years to provide Python scripts under Windows. Now I'm experimenting
> it under Unix (Linux / Solaris).
>
> When I run Configure.py, I got the following message:
>
> I: Finding TCL/TK...
> I: could not find TCL/TK  <<<---
>

> [...]

[akineko]

Hello Simone Ramacci,

Thank you for letting me know that the PyInstaller can find TCL/TK
under your environment.
I always compile Python from src and don't use IDLE (I won't install
any package unless I'm convinced it is necessary).

If you don't mind, can you post the directory listing of lib-dynload/
in your environment?
The directory contains dynamic link libraries (/usr/local/lib/
python2.5/lib-dynload/ in my environment).
I think there are some additional files in your directory helping
Configure.py to find TCL/TK path.

Thank you!
Aki Niimura

[Simone Ramacci - Simosito.it]

akineko ha scritto:

On my O.s. (Ubuntu 8.04) the only thing in /usr/local/lib/python is the
site-packages directory.
What's your O.s.? (What Linux/Solaris distribution and/or version)

Why don't you see what ./Configure says if you try to build the IDLE?
If it can't find Tcl/tk either, maybe there is something wrong in your
system.

Let me know,
Simone Ramacci

P.s.

My tcl version is 8.4.

[akineko]

Hello Simone Ramacci,

Some Linux distributions changed how software packages are installed.
Instead of prefix=/usr/local, they used prefix=/usr, which I don't
like.
You can find your python installation under /usr/, and dynamic link
libaries are possibly under:
(1) /usr/lib/python2.x/lib-dynload
(2) /usr/lib64/python2.x/lib-dynload
2.x = 2.4 or 2.5 or ...

If you install Python from src, all goes under /usr/local unless you
changed prefix.
I asked you the directory listing as I knew ./Configure uses ldd to
find the path.

IDLE could be the reason for this as IDLE uses GUI.
I will experiment by myself.

Thanks,
Aki Niimura

On Jun 26, 3:07 am, "Simone Ramacci - Simosito.it"

[Simone Ramacci - Simosito.it]

#ls /usr/lib/python2.5/lib-dynload
array.so _csv.so imageop.so rgbimg.so
audioop.so _ctypes.so itertools.so select.so
binascii.so _ctypes_test.so linuxaudiodev.so _socket.so
_bisect.so _curses_panel.so _locale.so spwd.so
_bsddb.so _curses.so _lsprof.so _sqlite3.so
bz2.so datetime.so math.so _ssl.so
cmath.so dbm.so mmap.so strop.so
_codecs_cn.so dl.so _multibytecodec.so _struct.so
_codecs_hk.so _elementtree.so nis.so syslog.so
_codecs_iso2022.so fcntl.so operator.so termios.so
_codecs_jp.so fpectl.so ossaudiodev.so _testcapi.so
_codecs_kr.so _functools.so parser.so time.so
_codecs_tw.so gdbm.so pyexpat.so _tkinter.so
collections.so grp.so Python-2.5.2.egg-info unicodedata.so

Does that help you somehow?

I hope it does.
Cheers,
Simone Ramacci

[akineko]

Hello Simone Ramacci,

Thank you for your prompt posting.
Yes, it does help my investigation.
Your lib-dynload contains _tkinter.so but no _tkinter.so in my lib-
dynload directory.
Now I found something interesting.
I found _tkinter.so in lib-dynload under lib/python2.4 but not under
lib/python2.5!
(My Tkinter programs works fine without _tkinter.so)

This may be something to do with how Python 2.5 deals with Tkinter.
Tkinter is now integrated into Python ditribution while it was a
separate external package in earlier Python releases.

I may reinstall Python 2.4 and try PyInstaller with it.

I will investigate further.

Thank you.
Aki Niimura

On Jun 26, 8:59 am, "Simone Ramacci - Simosito.it"

[Simone Ramacci - Simosito.it]

> Thank you for your prompt posting.
> Yes, it does help my investigation.
> Your lib-dynload contains _tkinter.so but no _tkinter.so in my lib-
> dynload directory.
> Now I found something interesting.
> I found _tkinter.so in lib-dynload under lib/python2.4 but not under
> lib/python2.5!
> (My Tkinter programs works fine without _tkinter.so)
>
> This may be something to do with how Python 2.5 deals with Tkinter.
> Tkinter is now integrated into Python ditribution while it was a
> separate external package in earlier Python releases.
>
>

> I will investigate further.
>
> Thank you.
> Aki Niimura
>
>

I don't think that python changed the way it implements Tk from v2.4 to
v2.5 (I found _tkinter.so into a py2.5 dir).
I've noticed that both under linux (package manager) and windows (setup)
the tk support can be installed separately.
Therefore, are you sure that when you run your script from console you
use py2.5 and not py2.4? Couldn't be possible that you didn't, somehow,
compiled well python 2.5?

Best regards,
Simone Ramacci

[akineko]

Hello Simone Ramacci,

I have been building Python from source for many years.
I'm using Python 2.5 and my Tkinter program is not using _tkinter.so
(I verified it using ldd and truss).
I'm almost fully convinced that the Python developers changed the way
Python interacts with Tkinter.
The reason why you have _tkinter.so in your lib-dynload is probably
the package creater included it for some reason.
That is the problem if you don't compile from scratch although it
saves time.

BTW, I compiled Python 2.4 again and found it generated _tkinter.so.
Python 2.5 is generating _tkinter.o (not .so) but no _tkinter.so.

Anyway, after the above experiments, I posted a question to Python
newsgroup hoping somebody clarifies this mystery.
I will update once I have a clear answer.

Aki Niimura

On Jun 26, 10:33 pm, "Simone Ramacci - Simosito.it"

[Simone Ramacci - Simosito.it]

akineko ha scritto:

You say that Python 2.5 create a file called _tkinter.o.
Looking on the web I found out that an .o file is an "object file
produced by a C compiler; often created instead of a program file during
the development process"
is therefore possible that the file _tkinter.o is just the _tkinter.so
not fully compiled?

BTW my config.dat file seems not to contain any ref. to lib-dynload nor
to any other /*/lib/python2.* subdir.

From my config.dat file:

'TCL_root': '/usr/lib/tcl8.4',
'TK_root': '/usr/lib/tk8.4',

Can this help you somehow?
(I wish I could do more, but I use Linux only since 7 years ago , when I
was 7 years-old. And I really ( = everyday) use it only since Ubuntu 7.10)

I hope you'll be lucky,
simone ramacci

[akineko]

I found there is a target in the Python 2.5 Makefile to create
_tkinter.so but not used.
_tkinter.o is used to create _tkinter.so but _tkinter.o is not a
dynamic load library.
I was thinking of tweaking the Makefile to generate _tkinter.so and
probably it will solve my problem.
But I would like to know how Python 2.5 is interacting with Tkinter
before monkeying around.

Aki Niimura

On Jun 27, 12:17 am, "Simone Ramacci - Simosito.it"

[Simone Ramacci - Simosito.it]

akineko ha scritto:

You don't have another pc you can use to do some tests, do you?
Maybe if you look on python.org you ca find something about.
why don't you ask in one official python ml?

Best regards,
Simone Ramacci

[akineko]

Hi,

I have spent time today to investigate this problem.
If you install Python with Tkinter from source on Unix environment,
_tkinter is built into the python executable (statically linked) and
no _tkinter.so is generated unless "shared" option is set.

This is why I didn't see _tkinter.so and why PyInstaller failed to
find the TCL/TK in my environment.

I found this by running python with '-v' option:
% python -v
...
>>> from Tkinter import *

...
import _tkinter # builtin <<<---

In the Module/Setup file:
# Uncommenting the following line tells makesetup that all following
# modules are to be built as shared libraries (see above for more
# detail; also note that *static* reverses this effect):

#*shared*

I tried to uncomment the line and I got successfully _tkinter.so under
python2.5/lib-dynload directory.

//

My further Internet search has yielded many compliants regarding to
missing _tkinter.so.
Probably this is why some packages on Linux includes _tkinter.so
(means "shared" option was set).
Therefore, probably this won't be a problem for most PyInstaller
users.

So, after this, did PyInstaller successfully find TCL/TK? Well, not
quite but that is another story.

BTW, by just placing _tkinter.so under python2.5/lib-dynload didn't
work unless Python was built with "shared" option. (PyInstaller is
checking only relevant imports)

Aki-