[Pythonmac-SIG] Has anyone running vtk+python on OSX?

[Robb Brown]

Hm.  Sounds like (3) is the right way... but it involves modifying 
VTK's auto-wrapper.  (1) sounds like maybe a quick fix?

Is (1) something that would be fairly easy for you try?  For (3), how 
hard is it to write something similar to import_libnumarray()?  I 
assume we'd have to do this for each VTK module and then insert the 
relevant calls.  Can we automatically create the tables as part of the 
wrapping process (that way the average VTK developer wouldn't have to 
do anything differently)?


On Friday, August 1, 2003, at 02:27 PM, Bob Ippolito wrote:

> There's three ways that I know of to do it:
> 	(1)	Inject Mach-O loader commands into the .so's that have 
> dependencies directly after compilation (something like 
> install_name_tool but more dangerous, I could write one of these using 
> the "potool" code I have)
> 	(2)	Trick the linker by whatever means.. i.e. not using -l, or 
> renaming to lib*.dylib then editing the Mach-O loaders with 
> install_name_tool after the fact.
> 	(3)	Fix VTK to use the recommended Python way for inter-extension 
> dependencies, like the way that numarray does it.  Basically what you 
> do is use Python to import the module containing the things you depend 
> on.  That module has a way of giving you various pointers to C 
> functions, and you setup a jump table based upon that.  See: 
> http://stsdas.stsci.edu/numarray/Doc/node37.html
>
> On Friday, Aug 1, 2003, at 16:20 America/New_York, Robb Brown wrote:
>
>> What's the recommended way of doing this?  If I understand correctly, 
>> we need to get rid of the -flat_namespace.  Doing this requires that 
>> we link some of the VTK Python modules with each other (eg. 
>> libvtkRenderingPython.so needs to be linked with 
>> libvtkCommonPython.so).  This happens on other platforms but VTK 
>> avoids this for the Mac.  Must have been a workaround in the early 
>> days when nobody could get ANYTHING to compile without flat 
>> namespaces in Apple's gcc.
>>
>> So how do you link  against a .so?  -l doesn't find them.  If we can 
>> figure this out I think it's relatively easy to modify VTK's cmake 
>> files to reflect the change.
>>
>> Thanks for any help,
>>
>> Robb
>>
>>
>> On Friday, August 1, 2003, at 11:27 AM, bob at redivi.com wrote:
>>
>>> On Fri, Aug 01, 2003 at 07:04:48PM +0200, Torsten Sadowski wrote:
>>>> Great news,
>>>>
>>>> I would also be interested in the things you did to make it work, 
>>>> because
>>>> - the carbon version did not build because of a problem between the 
>>>> tk and
>>>> 	the carbon framework
>>>> - the python test failed because the wrapper libraries were not 
>>>> linked
>>>> 	together.
>>>
>>> That's what it look like to me.  It looks like their Python wrappers 
>>> are currently expecting -flat_namespace -undefined suppress and a 
>>> specific import order.. but Python is not linking the .so's that >>> way.
>>>
>>> The best way to do this would be to fix the VTK build process so 
>>> that it links hte dependent libraries together and doesn't mess up.  
>>> That's really NOT the way to do extension->extension dependencies in 
>>> Python, though.
>>>
>>> -bob
>>>
>>> _______________________________________________
>>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>>
>>>
>> _____________________________
>> Robb Brown
>> Seaman Family MR Center
>> Calgary, AB
>>
>
>
_____________________________
Robb Brown
Seaman Family MR Center
Calgary, AB