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

[Bob Ippolito]

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
>