Re: [Fink-devel] Problem building vtk-py25

[Dr. W. S. <Wolfram.Schroers@Field-theory.org>]

If there was any other way to just get mayavi(2) running it would certainly be good enough. I recall that some time ago there was a Windows binary distribution which contained all necessary libraries in the binary and did not require installing any further dependencies. Would it be an option to just use precompiled libraries and the binary from older systems? (Unfortunately, I don't have access to a older Intel Mac system.)


> Dr. Wolfram Schroers wrote:
>> No, I do not need this old version. However, I wanted to install mayavi2 (or, at least, the older mayavi) and this is a required dependency. If one could also use the more recent vtk, I would be very happy to use that one, instead.
> 
> Ah yes, forgot about mayavi. The problem with more recent versions of vtk is that in python "import vtk" does not work, because of linking problems of the python modules.
> 
> There are several different ways of resolving the python-supplied symbols in python modules, and so far I have not had success with any of them. This is a very time-consuming process, not only because vtk takes a long time to compile, but mainly because of the cmake build system, which is a royal PITA in this situation. Trying to convince it to use a certain linker flag and to link or not to link to a certain library is a major hacking challenge.
> 
> If anyone on the list wants to give it a try, I'd be happy. The possibilities are:
> 
> 1. Let cmake do what it wants (after setting a lot of cmake flags, of course). This resolves undefined symbols from libpython2.5.dylib and links the modules with that dylib. For many python modules (and this happens with vtk52 and vtk54, but strangely not with vtk50), this situation leads to the famous "interpreter version mismatch" crash when the module is imported into python. I think this problem might disappear with python2.6, but I haven't had time to check.
> 
> 2. Add the "-bundle_loader /sw/bin/python2.5" linker flag. This uses the python executable to resolve symbols. It is the recommended method for linking python modules, but most of the time leads to linker errors.
> 
> 3. Try to get rid of libpython.dylib on the linker line and add either "-undefined dynamic_lookup" or "-flat_namespace -undefined suppress". This works for many python modules, but with vtk I got linker errors, too.
> 
> I'll continue trying this, but I cannot estimate when I will succeed. In any case, I will never try to fix anything that involves funny java compiler errors.
> 
> -- 
> Martin
> 
> 
> 
> 
> 
> 
> 
>