[vtkusers] Interacting with VTK under Mac OS X

[Martin Costabel]

Mike Jackson wrote:
> Here is the deal. You have TWO choices. Pick ONE..

Unfortunately, both don't make sense when you use a package manager like 
MacPorts or Fink or even Xcode. It is a pity that the cmake developers 
don't understand this.

> 1) Build with RPATH=ON. This will encode the full path to the libraries 
> in each library. So basically, build VTK with RPATH=ON and then DO NOT 
> MOVE THE LIBRARIES from wherever cmake puts them. In Xcode, you 
> reference these libraries IN PLACE. This is what you want to use when 
> developing.
> 
> 2) Build with RPATH=OFF but do a "make install". This will place the 
> libraries in /usr/local/lib by default and Encode in each library where 
> the library is located. This is what you want to use when Deplorying 
> your app to other people. You will need an installer than places all the 
> Vtk libs in /usr/local/lib for the user. While this will work and some 
> companies do it this way, this is really NOT the mac way of doing things.

In linux, it is quite obvious that you have *three* locations, the build 
tree, the package build tree where the first provisional installation 
happens, and the final install location. For any package manager system, 
even on MacOSX, the situation is the same. Cmake doesn't understand 
this, while gnu libtool, for example, has sophisticated and well-tested 
methods to implement this on MacOSX.

The install_name of the dylibs must be different from the place where 
the dylib is created and also different from the place where it is first 
installed. This is impossible to do with the current versions of cmake, 
unless one hacks either cmake, as you seem to be doing, or the build 
process, as the Fink builds of vtk and paraview are currently doing.

> And a few comments from below: OS X does NOT put the path in the 
> libraries name, the linker does only with flags that are set by CMake.

Every dylib has an install_name. even if it has no path in front of the 
library name. And this install_name is hardcoded into every binary that 
is linked with this dylib.

> What I would like to see are two more options for OS X:
>   1) Do not encode ANY path in the libraries. OS X by DEFAULT will look 
> in /usr/lib and /usr/local/lib (preferable) for libraries. This would be 
> a better situation. 

It is not really documented where dyld really looks in this case, 
probably also in the current directory. I wouldn't be surprised if the 
rules concerning this non-standard situation changed without warning 
from time to time. Dylibs without path component in their install_name 
are usually created by mistake, or by build systems like cmake or qt 
that don't really understand MacOSX.

>   2) Provide an option to set the "install_name" for the libraries, or 
> at least the prefix. I have my own hack in the OS X CMake module that 
> allows me to do this. Thus I can compile my VTK libs with a path like 
> the following: "@executable_path/../Libs" which allows me to embed all 
> the VTK libs in my .app package. This allows true "Drag and Drop" 
> installation of your application onto the OS X system. No Installer needed.

To have an option to set the install_name is an absolute necessity for 
any serious build system on MacOSX. Cmake's documentation seems to imply 
that you can do this by some suitable combination of variables like 
RPATH, CMAKE_INSTALL_NAME_DIR, CMAKE_BUILD_WITH_INSTALL_RPATH and so on, 
but I have never been able to make this work without additional evil hacks.

> You should NOT have to mess with DYLD_LIBRARY_PATH environment variables 
> if this is setup correctly.

This is very true.

A final remark:
We are talking only about install_name here, but the situation is worse 
with respect to compatibility_version which the cmake people do not seem 
to have heard about, but which is also an important feature of Darwin 
dylibs.

-- 
Martin