[vtkusers] OSX Mountain Lion - shared libraries

[Boxer, Aaron]

On Thu, 23 Jan 2014 20:59:15 -0700, David Gobbi said:

>When you build VTK, or when you build your own programs against the VTK 
>libraries, cmake bakes the load path into the libraries and the 
>executables that it produces.  So in general, no paths have to be set.
> The run-time libraries will be found automatically.
>
>CMake will strip out these baked-in library paths when you run a make 
>install, so that the installed VTK programs will only search the system 
>library paths, rather than searching your build directory for the 
>libraries.  So if you install libraries to some location that is not in 
>the system library path, then you will need to use DYLD_LIBRARY_PATH or 
>some other path-setting mechanism.
>
>More information (general info, not specific to OS X) is available on 
>the wiki: http://www.cmake.org/Wiki/CMake_RPATH_handling

And it is the complication of shared libraries having these built-in paths that makes static libraries preferable in many situations.

Of course, as with everything, "it depends" what you're doing.  Aaron, what are you doing with VTK exactly?  If you are trying to build a stand-alone .app then using static libraries will be preferable because the linker will just add them to your main executable, and you won't have to worry about embedding the dylibs in your .app, plus the linker will be able to dead strip a lot of VTK away for you.

Thanks, Sean.  I am working with Osirix, a medical imaging viewer that uses VTK to do 3D rendering.  It is a standalone app. 
The current project uses static libraries. I am exploring the shared library option to speed up compile time in development.  

Cheers,
Aaron




This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. 
Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. 
If you have received this e-mail in error, please contact the sender and delete all copies. 
Opinions, conclusions or other information contained in this e-mail may not be that of the organization.