[CMake] cmake variables to control full path in shared lib on OSX

Darren Weber darren.weber.lists at gmail.com
Fri Sep 19 16:44:57 EDT 2008


On Fri, Sep 19, 2008 at 12:30 PM, Darren Weber
<darren.weber.lists at gmail.com> wrote:
> On Thu, Sep 18, 2008 at 11:35 PM, Martin Costabel <costabel at wanadoo.fr> wrote:
>> 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
>>
>>
>
>
> I have a testing build that seems to create paths within the build
> tree that are specific to the build, but once they are installed all
> the paths are updated to the install path, ie:
>
> [ dweber at elegans ~/src/kitware/VTK_build ]$ otool -L
> bin/libvtkHybrid.5.2.0.dylib
> bin/libvtkHybrid.5.2.0.dylib:
>        /Users/dweber/src/kitware/VTK_build/bin/libvtkHybrid.5.2.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> <snip>
>        /Users/dweber/src/kitware/VTK_build/bin/libvtkfreetype.5.2.dylib
> (compatibility version 0.0.0, current version 0.0.0)
>        /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
> (compatibility version 1.0.0, current version 1.0.0)
>        /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
> (compatibility version 1.0.0, current version 12.0.0)
>        /Users/dweber/src/kitware/VTK_build/bin/libvtksys.5.2.dylib
> (compatibility version 0.0.0, current version 0.0.0)
> <snip>
>        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 111.1.1)
>        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
>        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>
> [ dweber at elegans ~/src/kitware/VTK_build ]$ otool -L
> /opt/local/lib/vtk-5.2/libvtkHybrid.5.2.0.dylib
> /opt/local/lib/vtk-5.2/libvtkHybrid.5.2.0.dylib:
>        /opt/local/lib/vtk-5.2/libvtkHybrid.5.2.dylib (compatibility version
> 0.0.0, current version 0.0.0)
> <snip>
>        /opt/local/lib/vtk-5.2/libvtkfreetype.5.2.dylib (compatibility
> version 0.0.0, current version 0.0.0)
>        /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
> (compatibility version 1.0.0, current version 1.0.0)
>        /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
> (compatibility version 1.0.0, current version 12.0.0)
>        /opt/local/lib/vtk-5.2/libvtksys.5.2.dylib (compatibility version
> 0.0.0, current version 0.0.0)
> <snip>
>        /opt/local/lib/vtk-5.2/libvtkverdict.vtk5.2.0.dylib (compatibility
> version 0.0.0, current version 0.0.0)
>        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 111.1.1)
>        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
>        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>
>
> However, I think the macport build is using the same cmake config
> settings, but the install paths for the libs are not updated.
> Currently checking into why that is (damn it!).
>
> Best, Darren
>


Well, macports has a default hi-jack of the 'make install' process.
It specifies a DESTDIR option that puts the whole install into a
staging process, to facilitate port management  (multiple verions,
install/uninstall, activate/deactivate, etc.).  So, this problem just
got a whole lot more difficult because the DESTDIR hi-jack creates a
temporary install path (as long your arm!), and then macports shifts
all the files around into several places before finally creating HARD
links from the /opt/local/lib* path to the actual macport installation
path (somewhere below /opt/local/var/macports/software/).  Hence, the
install path that you THINK you get is not what you REALLY get.
Hence, the maxim, thoughts can be deceiving!  Also, the maxim, it pays
to RTFM ;-)
http://guide.macports.org/chunked/reference.phases.html

So, now I have to figure out how to adjust the rpath so it is a fixed
value that doesn't depend on the build or the install path, because
both of these are bogus for macport build/install processes.

Going slightly crazy, Darren


More information about the CMake mailing list