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

Bruce Southey bsouthey at gmail.com
Fri Jul 15 10:31:58 EDT 2011


On 07/15/2011 01:55 AM, Ralf Gommers wrote:
>
>
> On Wed, Jul 13, 2011 at 11:10 PM, Ilan Schnell <ischnell at enthought.com 
> <mailto: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
I did not think that numpy uses X11 so this is just some system output 
that may be useful for the user. Yes, a ticket could be filed but 
Debian's multarch support is so 'new' (announcement thread: 
http://thread.gmane.org/gmane.linux.debian.devel.announce/1609).

I think it is is premature to address multarch support yet because it 
does require a specific version of numpy only using the correct 
libraries when the user has multiple architecture versions installed. 
That will also be a problem here because just adding the paths alone is 
probably insufficient for the application to find the correct libraries.

Bruce




>
>
>      Please the the forwarded conversation
>     below.
>
>     Thanks   Ilan
>
>
>     ---------- Forwarded message ----------
>     From: Varun Hiremath <varunhiremath at gmail.com
>     <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>     <mailto:Enthought-Dev at mail.enthought.com>
>     >>> >> > https://mail.enthought.com/mailman/listinfo/enthought-dev
>     >>> >> >
>     >>> >> _______________________________________________
>     >>> >> Enthought-Dev mailing list
>     >>> >> Enthought-Dev at mail.enthought.com
>     <mailto:Enthought-Dev at mail.enthought.com>
>     >>> >> https://mail.enthought.com/mailman/listinfo/enthought-dev
>     >>> > _______________________________________________
>     >>> > Enthought-Dev mailing list
>     >>> > Enthought-Dev at mail.enthought.com
>     <mailto:Enthought-Dev at mail.enthought.com>
>     >>> > https://mail.enthought.com/mailman/listinfo/enthought-dev
>     >>> >
>     >>> _______________________________________________
>     >>> Enthought-Dev mailing list
>     >>> Enthought-Dev at mail.enthought.com
>     <mailto:Enthought-Dev at mail.enthought.com>
>     >>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>     >> _______________________________________________
>     >> Enthought-Dev mailing list
>     >> Enthought-Dev at mail.enthought.com
>     <mailto:Enthought-Dev at mail.enthought.com>
>     >> https://mail.enthought.com/mailman/listinfo/enthought-dev
>     >>
>     > _______________________________________________
>     > Enthought-Dev mailing list
>     > Enthought-Dev at mail.enthought.com
>     <mailto:Enthought-Dev at mail.enthought.com>
>     > https://mail.enthought.com/mailman/listinfo/enthought-dev
>     >
>     _______________________________________________
>     Enthought-Dev mailing list
>     Enthought-Dev at mail.enthought.com
>     <mailto:Enthought-Dev at mail.enthought.com>
>     https://mail.enthought.com/mailman/listinfo/enthought-dev
>     _______________________________________________
>     NumPy-Discussion mailing list
>     NumPy-Discussion at scipy.org <mailto:NumPy-Discussion at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
> _______________________________________________
> 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/d23d34b4/attachment.html>


More information about the NumPy-Discussion mailing list