[Numpy-discussion] Fwd: [Enthought-Dev] Linking issues with libX11.so

Ralf Gommers ralf.gommers at googlemail.com
Fri Jul 15 02:55:38 EDT 2011 

On Wed, Jul 13, 2011 at 11:10 PM, Ilan Schnell <ischnell at 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 at gmail.com>
> Date: Wed, Jul 13, 2011 at 4:03 PM
> Subject: [Enthought-Dev] Linking issues with libX11.so
> To: enthought-dev at 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 at 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
> >
> https://github.com/enthought/enable/commit/ebecdbfc5c4596282204e61ff687c3ab2442947a
> > 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
> problem,
> > 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 at 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",
> line 86, in <module>
> >>    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 at 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/4f36a8a27cfa131347dd90d1a8e10a37358cf634
> >>> >>
> >>> >> 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 at 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",
> line 195, in main
> >>> >> >    app.run()
> >>> >> >  File
> "/usr/lib/python2.6/dist-packages/mayavi/plugins/mayavi_workbench_application.py",
> line 81, in run
> >>> >> >    window.open()
> >>> >> >  File
> "/usr/lib/python2.6/dist-packages/pyface/workbench/workbench_window.py",
> line 144, in open
> >>> >> >    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",
> line 217, in _create_contents
> >>> >> >    contents = self.layout.create_initial_layout(parent)
> >>> >> >  File
> "/usr/lib/python2.6/dist-packages/pyface/ui/wx/workbench/workbench_window_layout.py",
> line 151, in create_initial_layout
> >>> >> >    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",
> line 39, in <module>
> >>> >> >    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",
> line 229, in validate
> >>> >> >    self.error( object, name, value )
> >>> >> >  File "/usr/lib/python2.6/dist-packages/traits/trait_handlers.py",
> line 168, in error
> >>> >> >    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",
> line 329, in _process
> >>> >> >    if time() > (self.time_stamp + 2.0):
> >>> >> > TypeError: 'NoneType' object is not callable
> >>> >> > ---------------
> >>> >> > _______________________________________________
> >>> >> > Enthought-Dev mailing list
> >>> >> > Enthought-Dev at mail.enthought.com
> >>> >> > https://mail.enthought.com/mailman/listinfo/enthought-dev
> >>> >> >
> >>> >> _______________________________________________
> >>> >> Enthought-Dev mailing list
> >>> >> Enthought-Dev at mail.enthought.com
> >>> >> https://mail.enthought.com/mailman/listinfo/enthought-dev
> >>> > _______________________________________________
> >>> > Enthought-Dev mailing list
> >>> > Enthought-Dev at mail.enthought.com
> >>> > https://mail.enthought.com/mailman/listinfo/enthought-dev
> >>> >
> >>> _______________________________________________
> >>> Enthought-Dev mailing list
> >>> Enthought-Dev at mail.enthought.com
> >>> https://mail.enthought.com/mailman/listinfo/enthought-dev
> >> _______________________________________________
> >> Enthought-Dev mailing list
> >> Enthought-Dev at mail.enthought.com
> >> https://mail.enthought.com/mailman/listinfo/enthought-dev
> >>
> > _______________________________________________
> > Enthought-Dev mailing list
> > Enthought-Dev at mail.enthought.com
> > https://mail.enthought.com/mailman/listinfo/enthought-dev
> >
> _______________________________________________
> Enthought-Dev mailing list
> Enthought-Dev at mail.enthought.com
> https://mail.enthought.com/mailman/listinfo/enthought-dev
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110715/31f19e41/attachment.html>

More information about the NumPy-Discussion mailing list