[vtkusers] Bizarre Python Errors

[Mike Robertson]

Awesome. It opens now. :) But, two things:
1. I can't install mayavi 1.1 and have the installed app work correctly.
Rather, I have to use mayavi 1.0 and run it directly from the terminal. It
returns a segmentation fault when I run the installed mayavi 1.1.

2. It's returning a rather unusual error when I run mayavi1.0. I've attached
an image of the error. (the heart example is empty)

mike


~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Michael Robertson
fermion at mac.com
http://thenewcosmos.com


"By [reason] we gain a multitude of cognitions, which although really
nothing more than elucidations or explanations of that which (though in a
confused manner) was already thought in our conceptions, are, at least in
respect of their form, prized as new introspections; whilst, so far as
regards their matter or content, we have really made no addition to our
conceptions, but only disinvolved them."

-Immanuel Kant, The Critique of Pure Reason



> From: Prabhu Ramachandran <prabhu at aero.iitm.ernet.in>
> Date: Wed, 1 May 2002 09:33:03 +0530
> To: Mike Robertson <fermion at mac.com>
> Cc: VTK users list <vtkusers at public.kitware.com>
> Subject: Re: [vtkusers] Bizarre Python Errors
> 
>>>>>> "MR" == Mike Robertson <fermion at mac.com> writes:
> 
>   MR> Sorry about the ignorance here, but how do you do that? I'm no
>   MR> expert on any of this. Started using unix a few months ago,
>   MR> honestly. Is there something within the VTK compile scripts
>   MR> that I need to change, or can I use my existing build and
>   MR> alter the library? Here's a directory listing (there's no
>   MR> libvtkRenderingPythonTkWidgets.o or
>   MR> libvtkRenderingPythonTkWidgets.c to use for their cryptic
>   MR> code.o, source.o, code.c, source.c distinctions). . . .
> 
>   MR> Thanks for all of your help. Hope this works.
> 
>   MR> [localhost:local/vtk/VTK] root# cd /usr/local/lib/vtk/
>   MR> [localhost:local/lib/vtk] root# ls libvtkCommon.a
>   MR> libvtkImaging.a libvtkCommonPython.so libvtkImagingPython.so
>   MR> libvtkCommonTCL.a libvtkImagingTCL.a libvtkFiltering.a
>   MR> libvtkRendering.a libvtkFilteringPython.so
>   MR> libvtkRenderingPython.so libvtkFilteringTCL.a
>   MR> libvtkRenderingPythonTkWidgets.dylib libvtkGraphics.a
>   MR> libvtkRenderingTCL.a libvtkGraphicsPython.so libvtkjpeg.a
>   MR> libvtkGraphicsTCL.a libvtkpng.a libvtkIO.a libvtkzlib.a
>   MR> libvtkIOPython.so tcl libvtkIOTCL.a [localhost:local/lib/vtk]
>   MR> root#
> 
> Well I'm a little confused here.  How come libvtkImaging.a is not a
> shared library?  However from your earlier posts it appears that this
> setup works, so lets not break it.
> 
> Anyway, to see how the libvtkRenderingPythonTkWidget.dylib is built go
> to your build directory and remove the
> libvtkRenderingPythonTkWidgets.dylib file.  Also remove the
> Rendering/vtkTkRenderWidgetPython.o (it will be in the Rendering
> directory).
> 
> Now simply cd to the base of your build dir and then run make again.
> You will see the command used to compile the
> Rendering/vtkTkRenderWidgetPython.o and the
> libvtkRenderingPythonTkWidgets.dylib.  Save the contents of make's
> output to a file.  Now check to see if the
> Rendering/vtkTkRenderWidgetPython.o is compiled with a -fno-common in
> it somewhere.  I guess that it will be.  If not just cd to the
> Rendering directory cut/paste the saved compile command, add a
> -fno-common and recompile.
> 
> Also check to see if the libvtkRenderingPythonTkWidgets.dylib is
> compiled with -bundle or -dynamiclib.  If you see -dynamiclib then
> replace it with -bundle, recompile the library alone and see what
> happens.
> 
> This shouldn't take more than a few minutes to do.
> 
> Let the list know how it goes.
> 
> prabhu
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 26355 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20020501/22823c81/attachment.jpeg>