build problems with TkAgg backend

Community matplotlib-users
1

Using the latest SVN matplotlib, the TkAgg backed does not get built
even though all the libraries are installed (Linux 64-bit). The
following error message occurs during the build:

Tkinter: no
         * Using default library and include directories for
         * Tcl and Tk because a Tk window failed to open.
         * You may need to define DISPLAY for Tk to work so
         * that setup can determine where your libraries are
         * located. Tkinter present, but header files are not
         * found. You may need to install development
         * packages.

This is even though lib64tk-devel and lib64tcl-devel are installed.
Strangely enough, when I remove lib64tcl-devel, the script proceeds
and picks up Tk, but it still can't determine the location of the
libraries (complains about not finding tkConfig.sh) - the build proceeds
but later fails because tcl.h is not found.

With both the tcl and tk headers installed, the only way actually to
build the TkAgg backend is to force it by
  [gui_support]
  tkagg = True
in setup.cfg. I still get the Tkinter error message given above, but
the backend builds successfully and I seem to be able to use it
without errors.

[jr@...2717... ~]$ locate tkConfig.sh
/usr/lib/tkConfig.sh
/usr/lib64/tkConfig.sh
/usr/lib64/tk8.6/tkConfig.sh
[jr@...2717... ~]$ locate tclConfig.sh
/usr/lib/tclConfig.sh
/usr/lib64/tclConfig.sh
/usr/lib64/tcl8.6/tclConfig.sh

System Info:

···

============================================================================
BUILDING MATPLOTLIB
            matplotlib: 0.99.0.rc1
                python: 2.6.1 (r261:67515, Apr 12 2009, 04:14:16)
[GCC
                        4.3.2]
              platform: linux2

REQUIRED DEPENDENCIES
                 numpy: 1.3.0
             freetype2: 9.20.3

OPTIONAL BACKEND DEPENDENCIES
                libpng: 1.2.35
               Tkinter: no
                        * Using default library and include
directories for
                        * Tcl and Tk because a Tk window failed to
open.
                        * You may need to define DISPLAY for Tk to work
so
                        * that setup can determine where your
libraries are
                        * located. Tkinter present, but header files
are not
                        * found. You may need to install development
                        * packages.
              wxPython: 2.8.9.2
                        * WxAgg extension not required for wxPython >=
2.8
                  Gtk+: gtk+: 2.16.1, glib: 2.20.1, pygtk: 2.14.1,
                        pygobject: 2.16.1
       Mac OS X native: no
                    Qt: no
                   Qt4: Qt: 4.5.0, PyQt4: 4.4.4
                 Cairo: 1.8.2

OPTIONAL DATE/TIMEZONE DEPENDENCIES
              datetime: present, version unknown
              dateutil: 1.4.1
                  pytz: 2008i

OPTIONAL USETEX DEPENDENCIES
                dvipng: 1.9
           ghostscript: 8.64
                 latex: 3.141592
               pdftops: 0.10.6

2

The message suggests you may not have access to the windowing system,
and the build process needs it to import tk. Are you building on a
remote box, or as root who may not have access to your user desktop?
If so, you can solve these problems by ssh with -X or otherwise make
sure that you can launch an X window in your build environment.

JDH

···

On Tue, Aug 4, 2009 at 3:52 AM, Johann Rohwer<jr@...841...> wrote:

Using the latest SVN matplotlib, the TkAgg backed does not get built
even though all the libraries are installed (Linux 64-bit). The
following error message occurs during the build:

Tkinter: no
* Using default library and include directories for
* Tcl and Tk because a Tk window failed to open.
* You may need to define DISPLAY for Tk to work so
* that setup can determine where your libraries are
* located. Tkinter present, but header files are not
* found. You may need to install development
* packages.

3

The message suggests you may not have access to the windowing system,
and the build process needs it to import tk. Are you building on a
remote box, or as root who may not have access to your user desktop?
If so, you can solve these problems by ssh with -X or otherwise make
sure that you can launch an X window in your build environment.

JDH

···

On Tue, Aug 4, 2009 at 3:52 AM, Johann Rohwer<jr@...841...> wrote:

Using the latest SVN matplotlib, the TkAgg backed does not get built
even though all the libraries are installed (Linux 64-bit). The
following error message occurs during the build:

Tkinter: no
* Using default library and include directories for
* Tcl and Tk because a Tk window failed to open.
* You may need to define DISPLAY for Tk to work so
* that setup can determine where your libraries are
* located. Tkinter present, but header files are not
* found. You may need to install development
* packages.

4

> Using the latest SVN matplotlib, the TkAgg backed does not get
> built even though all the libraries are installed (Linux 64-bit).
> The following error message occurs during the build:
>
> Tkinter: no
> * Using default library and include directories for
> * Tcl and Tk because a Tk window failed to open.
> * You may need to define DISPLAY for Tk to work so
> * that setup can determine where your libraries are
> * located. Tkinter present, but header files are not
> * found. You may need to install development
> * packages.

The message suggests you may not have access to the windowing
system, and the build process needs it to import tk. Are you
building on a remote box, or as root who may not have access to
your user desktop?

No, I'm building as a normal user on the local machine.

[jr@...2717... ~]$ echo $DISPLAY
:0.0

Furthermore I can create Tk objects:
[jr@...2717... ~]$ python
Python 2.6.1 (r261:67515, Apr 12 2009, 04:14:16)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.

import Tkinter
a=Tkinter.tkinter.create()

which creates a tk window on my desktop.

So really in the dark what's going on here....
Johann

···

On Tuesday 04 August 2009, John Hunter wrote:

On Tue, Aug 4, 2009 at 3:52 AM, Johann Rohwer<jr@...841...> wrote:

5

Very odd. I suggest opening up setupext.py and finding the function
"check_for_tk". There are a series of test which ultimately set the
"gotit" variable to determine whether you have tk for building.
Insert a lot of debug print statements throughout the logic of that
function and find out where it is failing and let us know.

My guess is you will fail in the "explanation = add_tk_flags(module)"
part of the code, so you may need to dive into there and repeat the
exercise to figure out what is failing and why. If you can repeat the
steps that the build process is attempting in your python shell, you
may be able to hone into the point of failure

JDH

···

On Tue, Aug 4, 2009 at 9:14 AM, Johann Rohwer<jr@...841...> wrote:

Type "help", "copyright", "credits" or "license" for more information.

import Tkinter
a=Tkinter.tkinter.create()

which creates a tk window on my desktop.

So really in the dark what's going on here....

6

What distro are you on? It seems that Tcl/Tk moves the header files around on a regular basis while not providing a standard way to determine their location. It's like a wild goose chase :wink: Perhaps you're running something new and blazing new territory here :wink:

Mike

John Hunter wrote:

···

On Tue, Aug 4, 2009 at 9:14 AM, Johann Rohwer<jr@...841...> wrote:

Type "help", "copyright", "credits" or "license" for more information.
    

import Tkinter
a=Tkinter.tkinter.create()
          

which creates a tk window on my desktop.

So really in the dark what's going on here....
    
Very odd. I suggest opening up setupext.py and finding the function
"check_for_tk". There are a series of test which ultimately set the
"gotit" variable to determine whether you have tk for building.
Insert a lot of debug print statements throughout the logic of that
function and find out where it is failing and let us know.

My guess is you will fail in the "explanation = add_tk_flags(module)"
part of the code, so you may need to dive into there and repeat the
exercise to figure out what is failing and why. If you can repeat the
steps that the build process is attempting in your python shell, you
may be able to hone into the point of failure

JDH

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

7

Michael Droettboom wrote:

What distro are you on? It seems that Tcl/Tk moves the header files around on a regular basis while not providing a standard way to determine their location. It's like a wild goose chase :wink: Perhaps you're running something new and blazing new territory here :wink:

Mandriva 2009.1 (64-bit)

Although the header files seem to me to be in pretty standard locations:
[jr@...2717... ~] locate tcl\.h /usr/include/tcl\.h /usr/include/tcl8\.6/generic/tcl\.h \[jr@\.\.\.2717\.\.\. \~\] ll /usr/include/tcl.h
-rw-r--r-- 1 root root 89652 2008-12-24 02:29 /usr/include/tcl.h
[jr@...2717... ~] ll /usr/include/tcl8\.6/generic/tcl\.h \-rw\-r\-\-r\-\- 1 root root 89652 2008\-12\-24 02:29 /usr/include/tcl8\.6/generic/tcl\.h \[jr@\.\.\.2717\.\.\. \~\] diff /usr/include/tcl.h /usr/include/tcl8.6/generic/tcl.h
[jr@...2717... ~]

8

OK, I've finally tracked this down. There are two issues:

1. On my system with Tk version 8.6
tk.getvar('tcl_library') returns /usr/share/tcl8.6 and
tk.getvar('tk_library') returns /usr/share/tk8.6

This means that TCL_TK_CACHE will contain these paths as tcl_lib_dir
and tk_lib_dir. Looking at the rest of the file, however, it appears
that /usr/lib64 is expected, or /usr/lib64/tk8.6 etc.

As a result, in parse_tcl_config (lines 858 ff.) the tclConfig.sh and
tkConfig.sh are not found due to this reason, since they reside
in/usr/lib64/tcl8.6/tclConfig.sh and /usr/lib64/tk8.6/tkConfig.sh and
not in /usr/share/...
Fortunately they are picked up by the hardcoded RHEL4 path (line
864-5) because they are symlinked to /usr/lib on my system.

2. From the config file (parse_tcl_config), tcl_lib is returned as
/usr/lib64 and tcl_inc as /usr/include/tcl8.6 (likewise for tk), which
appears to be OK. However, the main problem is that the method fails
(returns None) when trying to locate tk.h (line 911-912). The reason
for this is that there again are 2 copies of tk.h on my system (the
files are identical):
  /usr/include/tk.h
  /usr/include/tk8.6/generic/tk.h
but not the expected /usr/include/tk8.6/tk.h. Since tk.h is not found,
the error message is generated. A similar error occurs in the
guess_tcl_config method due to the location of tk.h (line 946-7)

I'm not sure if/how to patch this and keep it generic, but at least it
tracks it down. I'm also not sure whether other Tk8.6 releases but
their header file in /usr/include/tk8.6/generic/tk.h or whether this is
Mandriva 2009.1 specific.

Johann

···

On Tuesday 04 August 2009, John Hunter wrote:

Very odd. I suggest opening up setupext.py and finding the
function "check_for_tk". There are a series of test which
ultimately set the "gotit" variable to determine whether you have
tk for building. Insert a lot of debug print statements throughout
the logic of that function and find out where it is failing and let
us know.

My guess is you will fail in the "explanation =
add_tk_flags(module)" part of the code, so you may need to dive
into there and repeat the exercise to figure out what is failing
and why. If you can repeat the steps that the build process is
attempting in your python shell, you may be able to hone into the
point of failure