[CMake] cmake variables to control full path in shared lib on OSX
Martin Costabel
costabel at wanadoo.fr
Fri Sep 19 02:35:41 EDT 2008
Darren Weber wrote:
> I'm exploring how to build and install VTK-5-2-0 on OSX. I'm trying
> to use shared libraries, but the default settings do not put full
> paths in the .dylib file links for the libvtk* libraries. I am using
> a non-standard install path (macports /opt/local), so I may need to
> set full paths for the libvtk* links. For example, this is just one
> of the dylib files and I may need all the links to libvtk* to contain
> the full path (/opt/local/lib/vtk-5.2/):
>
>[]
>
> What are the right cmake variables that will enable full paths in the
> shared libraries?
Here is what works for me (I am creating a Fink package, which is a very
similar situation to yours):
-DBUILD_SHARED_LIBS:BOOL=ON \
-DVTK_INSTALL_LIB_DIR:STRING="/lib/vtk52" \
-DCMAKE_INSTALL_PREFIX:PATH=%p \
-DCMAKE_INSTALL_NAME_DIR:STRING=%p/lib/vtk52 \
-DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
-DVTK_USE_RPATH=ON \
Here %p corresponds to your ${prefix}. There is one catch, however:
VTK builds a couple of executables that are used during building like
"ProcessShader". If you use the above flags, these executables will
crash, because they look for the dylibs they are linked with at their
install location, where they are not yet installed. They must be told to
look for the dylibs in the build tree instead.
Gnu libtool has a mechanism to deal with this situation (creating
temporary wrapper scripts for each executable), but if cmake has one, I
haven't found it. What works for me is to set
export DYLD_FALLBACK_LIBRARY_PATH=`pwd`/bin
after the cmake run, just before running `make`. This uses the fact that
the dylibs are built in the same directory build/bin as the executables.
But it is not an optimal workaround, because if you have an older
version of vtk installed, the binaries will find these older versions
first and perhaps not run either. Setting DYLD_LIBRARY_PATH instead of
DYLD_FALLBACK_LIBRARY_PATH has too many side effects to be usable.
--
Martin
More information about the CMake
mailing list