On Wed, Jul 13, 2011 at 11:10 PM, Ilan Schnell <ischnell@enthought.com>wrote:
Hello List,
Varun, who is a debian packager ran into some problems while compiling Enable, as it uses numpy.distutils, which did not locate the location of the X11 libraries correctly. Maybe this can be fixed in the numpy 1.6.1 release.
It's a bit late for that, since we're at 1.6.1rc3, this is not a patch and I'm not even sure it should be fixed in numpy.distutils. Right now the searched dirs are ['/usr/X11R6/lib', '/usr/X11/lib', '/usr/lib'] or its 64-bit equivalents. See around line 200 in system_info.py. Is your proposal to add any arch-dependent paths that Debian can think of to that? Leaving it up to the packager to specify the correct path in site.cfg may be cleaner. Or just apply the patch you received to the ETS Agg build. Cheers, Ralf Please the the forwarded conversation
below.
Thanks Ilan
---------- Forwarded message ---------- From: Varun Hiremath <varunhiremath@gmail.com> Date: Wed, Jul 13, 2011 at 4:03 PM Subject: [Enthought-Dev] Linking issues with libX11.so To: enthought-dev@enthought.com
Hi Ilan,
You were right, the issue was with the X11 library. The _plat_support.so was not linked to libX11 and so the chaco examples were failing; and the reason libX11 was not linked was because numpy distutils' x11_info was failing.
I figured out that in debian/ubuntu with a new multi_arch build support [1] the libraries are being moved from the standard /usr/lib and /usr/lib64 directories to architecture specific directories like:
/usr/lib/i386-linux-gnu/ /usr/lib/x86_64-linux-gnu/
and so the numpy.distutil was failing to find libX11 with the latest version of libX11-dev on debian which installs libX11.so in /usr/lib/x86_64-linux-gnu/ (on my amd64 system). The nump.distutils' scripts need to be updated to handle this, but for now I am using the following patch to force _plat_support.so link with X11 (which I think is always present in the default search path):
--------------------------- @@ -230,6 +144,7 @@ elif plat in ['x11','gtk1']: x11_info = get_info('x11', notfound_action=1) dict_append(plat_info, **x11_info) + dict_append(plat_info, libraries = ['X11'])
---------------------------
With this everything seems to be working fine!
Thanks, Varun
[1] https://wiki.ubuntu.com/MultiarchSpec
On Mon, Jul 11, 2011 at 10:53 PM, Ilan Schnell <ischnell@enthought.com> wrote:
Hello Varun,
the important part is: _plat_support.so: undefined symbol: XCreateImage This indicates that the kiva/agg/_plat_support.so C extension was not linked to X11 while compiling. Until
which was made shortly after the release, it was easy to create a broken Enable build like this one. Note that this commit does *not* fix the
it only causes the build to fail right away, instead of creating a broken build. This was added because of the famous esr quote: "When you must fail, fail noisily and as soon as possible."
As enable uses numpy.distutils to build agg, the fix is to edit: <python prefix>/lib/python2.6/site-packages/numpy/distutils/site.cfg
and add: [x11] library_dirs = ... include_dirs = ...
- Ilan
On Mon, Jul 11, 2011 at 9:23 PM, Varun Hiremath <varunhiremath@gmail.com> wrote:
Hi all,
I am facing another issue running chaco examples with the new ETS 4.0 packages. I am getting the following error when I run any chaco example: -------------------------- $$ python zoom_plot.py /usr/lib/python2.6/dist-packages/enable/wx/image.py:16: Warning: Error initializing Agg: /usr/lib/python2.6/dist-packages/kiva/agg/_plat_support.so: undefined symbol: XCreateImage from kiva.agg import CompiledPath, GraphicsContextSystem as GraphicsContext Traceback (most recent call last): File "zoom_plot.py", line 15, in <module> from enable.api import Component, ComponentEditor File "/usr/lib/python2.6/dist-packages/enable/api.py", line 42, in <module> from graphics_context import GraphicsContextEnable, ImageGraphicsContextEnable File "/usr/lib/python2.6/dist-packages/enable/graphics_context.py",
class GraphicsContextEnable(EnableGCMixin, GraphicsContext): TypeError: Error when calling the metaclass bases metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases -------------------------
Does anybody know what could be the problem?
Thanks, Varun
p.s. Most of the ETS 4.0 debian packages are now available in debian unstable.
On Sat, 09 Jul, 2011 at 12:45:32PM -0500, Ilan Schnell wrote:
I'm glad it worked. That's a good idea, I'll release traitsui-4.0.1 later today.
- Ilan
On Sat, Jul 9, 2011 at 11:20 AM, Varun Hiremath < varunhiremath@gmail.com> wrote:
Hi Ilan,
Thanks, that worked! Are you planning on doing a point release for traitsui to fix this bug? It would make packaging easier then.
Thanks, Varun
On Sat, 09 Jul, 2011 at 11:11:26AM -0500, Ilan Schnell wrote:
Hello Varun,
I ran into the same bug when preparing the EPD 7.1 release. The fix is commited to the github master of traitsui:
https://github.com/enthought/traitsui/commit/4f36a8a27cfa131347dd90d1a8e10a3...
Just replace the two zip-files with the fixed ones, and it should
work.
- Ilan
On Sat, Jul 9, 2011 at 10:27 AM, Varun Hiremath <
varunhiremath@gmail.com> wrote:
> Hi, > > I was trying to update the debian packages to the new ETS 4.0 release, > but I am having some trouble getting mayavi2 running. I get the error > shown below when I run mayavi2. Could someone please let me know what > might be causing this error? > > Thanks, > Varun > > ----------------- > $ mayavi2 > Traceback (most recent call last): > File "/usr/bin/mayavi2", line 658, in <module> > main() > File "/usr/bin/mayavi2", line 649, in main > mayavi.main(sys.argv[1:]) > File "/usr/lib/python2.6/dist-packages/mayavi/plugins/app.py",
> app.run() > File "/usr/lib/python2.6/dist-packages/mayavi/plugins/mayavi_workbench_application.py",
> window.open() > File "/usr/lib/python2.6/dist-packages/pyface/workbench/workbench_window.py",
> self._create() > File "/usr/lib/python2.6/dist-packages/pyface/ui/wx/application_window.py", line 150, in _create > contents = self._create_contents(body) > File "/usr/lib/python2.6/dist-packages/pyface/workbench/workbench_window.py",
> contents = self.layout.create_initial_layout(parent) > File "/usr/lib/python2.6/dist-packages/pyface/ui/wx/workbench/workbench_window_layout.py",
> self._wx_view_dock_window = WorkbenchDockWindow(parent) > File "/usr/lib/python2.6/dist-packages/pyface/dock/dock_window.py", line 324, in __init__ > if self.theme.use_theme_color: > File "/usr/lib/python2.6/dist-packages/pyface/dock/dock_window.py", line 335, in _theme_default > return dock_window_theme() > File "/usr/lib/python2.6/dist-packages/traitsui/dock_window_theme.py", line 92, in dock_window_theme > from .default_dock_window_theme import default_dock_window_theme > File "/usr/lib/python2.6/dist-packages/traitsui/default_dock_window_theme.py",
> label = ( 0, -3 ), content = ( 7, 6, 0, 0 ) ), > File "/usr/lib/python2.6/dist-packages/traitsui/theme.py", line 63, in __init__ > self.image = image > File "/usr/lib/python2.6/dist-packages/traitsui/ui_traits.py",
> self.error( object, name, value ) > File "/usr/lib/python2.6/dist-packages/traits/trait_handlers.py",
> value ) > traits.trait_errors.TraitError: The 'image' trait of a Theme instance must be an ImageResource or string that can be used to define one, but a value of '@std:tab_active' <type 'str'> was specified. > Exception in thread Thread-1: > Traceback (most recent call last): > File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner > self.run() > File "/usr/lib/python2.6/threading.py", line 484, in run > self.__target(*self.__args, **self.__kwargs) > File "/usr/lib/python2.6/dist-packages/traitsui/image/image.py",
https://github.com/enthought/enable/commit/ebecdbfc5c4596282204e61ff687c3ab2... problem, line 86, in <module> line 195, in main line 81, in run line 144, in open line 217, in _create_contents line 151, in create_initial_layout line 39, in <module> line 229, in validate line 168, in error line 329, in _process
> if time() > (self.time_stamp + 2.0): > TypeError: 'NoneType' object is not callable > --------------- > _______________________________________________ > Enthought-Dev mailing list > Enthought-Dev@mail.enthought.com > https://mail.enthought.com/mailman/listinfo/enthought-dev > _______________________________________________ Enthought-Dev mailing list Enthought-Dev@mail.enthought.com https://mail.enthought.com/mailman/listinfo/enthought-dev
Enthought-Dev mailing list Enthought-Dev@mail.enthought.com https://mail.enthought.com/mailman/listinfo/enthought-dev
_______________________________________________ Enthought-Dev mailing list Enthought-Dev@mail.enthought.com https://mail.enthought.com/mailman/listinfo/enthought-dev
Enthought-Dev mailing list Enthought-Dev@mail.enthought.com https://mail.enthought.com/mailman/listinfo/enthought-dev
_______________________________________________ Enthought-Dev mailing list Enthought-Dev@mail.enthought.com https://mail.enthought.com/mailman/listinfo/enthought-dev
_______________________________________________ Enthought-Dev mailing list Enthought-Dev@mail.enthought.com https://mail.enthought.com/mailman/listinfo/enthought-dev _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion