[CMake] padding link arguments to the linker
Mike Jackson
imikejackson at gmail.com
Wed Feb 8 11:04:05 EST 2006
On Feb 8, 2006, at 10:37 AM, Brad King wrote:
> Brad King wrote:
>> The VTK CMake code provides an interface to allow some
>> customization of the build. Create a file Common/
>> LocalUserOptions.cmake in either the VTK build tree or the source
>> tree. Add this line:
>> SET_TARGET_PROPERTIES(vtkCommon PROPERTIES LINK_FLAGS
>> "-install_name @executable_path/../Plugins/libvtkCommon.dylib")
>
> You might also be interested in this tool:
>
> http://developer.apple.com/documentation/Darwin/Reference/ManPages/
> man1/install_name_tool.1.html
>
> -Brad
Yes.. I have used that tool on some other libraries. The problem is
that the path that is stored in the library must be the same length
or LONGER than the path you want to change it to. So I did a
make;make install on VTK. Running otool -L on /usr/local/lib/
libvtkCommon.dylib gives:
110:[mjackson at Aeryn:/usr/local/lib]$ otool -L libvtkCommon.dylib
libvtkCommon.dylib:
libvtkCommon.dylib.5.0 (compatibility version 0.0.0, current
version 0.0.0)
libvtksys.dylib.5.0 (compatibility version 0.0.0, current
version 0.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/
AppKit (compatibility version 45.0.0, current version 824.33.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.1.2)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.3.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
So here the problem is that I want to replace:
libvtkCommon.dylib.5.0
with
@executable_path/../Plugins/libvtkCommon.dylib
This isn't going to work because I want to replace a shorter path
with a longer path.
Now, the whole reason I am going down this path is to be able to
include the dylibs in my app package and not have the user have to
"install" vtk into /usr/local/lib which may require Admin privileges.
I would rather give them a single .app package that they can drag and
drop where ever they choose.
So to have to create a cmake file for each module, while it should
work, isn't necessarily the most efficient solution. Is there a way
to work this into cmake itself?
Thanks
Mike Jakckson
More information about the CMake
mailing list