[vtkusers] Ongong woes building vtk on Mac OSX

[Sander Niemeijer]

Hi Jens,

I'm glad you got it working.

Let me provide some additional information, since some options are not  
really necessary.

> I haven't ended up doing it exactly as was suggested, as I couldn't  
> get it to work for me: if I tried to build the shared library from  
> libpython2.3a, I got:
>
> cc -dynamiclib -all_load -framework System -framework CoreServices  
> -framework Foundation ./lib/python2.3/config/libpython2.3.a -o  
> ./lib/libpython2.3.dylib -install_name ./python/lib/libpython2.3.dylib  
> -current_version 2.3 -compatibility_version 2.3
> ld: Undefined symbols:
> _environ
> /usr/bin/libtool: internal link edit command failed

Did you try this with Python-2.3.3 or Python-2.3.4? And did this Python  
build use -fno-common or not?

> 1. I downloaded Python 2.3.4 into my home directory and configured it  
> with:
>
> ./configure --prefix=/Users/jens/Python-2.3.4 -with-dyld

The -with-dyld option is ignored by the configure script (and you  
probably meant --with-dyld (2 dashes)).
When you run configure you should also see:
---
checking for dyld... always on for Darwin
---
So explicitly enabling dyld is not needed.

> then edited the Makefile to add the following flags to BASECFLAGS:
>
>  -fno-common -fPIC

The -fPIC does not seem to be needed on Mac OS X (according to  
documentation I found in GNU libtool, PIC objects are the default on  
the Mac). You only need to provide -fno-common on Mac OS X to create a  
shared library (the -fno-common option is explained at  
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/ 
MachORuntime/Overview/chapter_2_section_3.html>).

There is also a difference between Python-2.3.3 and Python-2.3.4.  
Python-2.3.3 automatically added the '-fno-common' option to the base  
flags, while Python-2.3.4 does not do this anymore.

Instead of editing your Makefile to add the -fno-common option, you can  
also provide a BASECFLAGS initialization with the configure script (the  
configure script of Python supports this).

So in your case, configuring Python-2.3.4 with

  ./configure --prefix=/Users/jens/Python-2.3.4  BASECFLAGS=-fno-common

should also work (and is a bit cleaner :-).

> running make and make install created the Python installation in  
> /Users/jens/Python-2.3.4
>
> 2.  I then checked out the latest CVS version of vtk  to the directory  
> (/Users/Jens/VTK) and made it with the following (these are what I  
> think are the relevant bits from my CMakeCache.txt):
>
> //Build VTK with shared libraries.
> BUILD_SHARED_LIBS:BOOL=ON
> //Python Framework
> PYTHON_DEBUG_LIBRARY:FILEPATH=/Users/jens/Python-2.3.4lib/python2.3/ 
> config/libpython2.3.a
> //Path to a program.
> PYTHON_EXECUTABLE:FILEPATH=/Users/jens/Python-2.3.4/bin/python2.3
> //What is the path where the file Python.h can be found
> PYTHON_INCLUDE_PATH:PATH=/Users/jens/Python-2.3.4/include/python2.3
> //Python Framework
> PYTHON_LIBRARY:FILEPATH=/Users/jens/Python-2.3.4/lib/python2.3/config/ 
> libpython2.3.a
> //Utility library needed for vtkpython
> PYTHON_UTIL_LIBRARY:FILEPATH=PYTHON_UTIL_LIBRARY-NOTFOUND
> //Install path prefix, prepended onto install directories.
> CMAKE_INSTALL_PREFIX:PATH=/Users/jens/VTK_INSTALL

Normally, you shouldn't link a static library against a shared library  
(because of the PIC problems), but since your static library of Python  
contains PIC objects this will indeed work out fine.
My guess however is that you will get quite large VTK Python modules  
because of this, since each VTK-Python module will now be linked  
statically with the Python library.

> (I linked against the framework version of tcl and tk, which were  
> picked up automatically and so I haven't included these).
>
> For some reason couldn't get ccmake to run a build outside the source  
> directory. I'm sure that before, I've created an empty directory (e.g  
> /Users/jens/VTK_INSTALL) cd'd to this and then run ccmake  
> /Users/jens/VTK (where VTK is the directory containing the source  
> files), and this has built everything in VTK_INSTALL.
>
> However, since this didn't work, after I ran make and make install, I  
> had to run the command:
>
> cmake -P cmake_install.cmake
>
> in /Users/jens/VTK to get the stuff copied across to  
> /Users/jens/VTK_INSTALL

I'm using cmake-1.8.3 and that doesn't have the '-P' option. So, I  
guess you are using a newer version. Could that be the cause of your  
problem?

> I then had to cd to /Users/jens/VTK/Wrapping/Python and run the  
> command:
>
> /Users/jens/Python-2.3.4/bin/python2.3 setup.py install
>
> to get the vtk into the python directory tree.
>
> After this, I could run /Users/jens/Python-2.3.4/bin/python2.3 and get  
> it to import vtk fine.

Best regards,
Sander