Hi,
On Oct 24, 2007, at 12:57 PM, Alan W. Irwin wrote:
On 2007-10-24 12:16-0600 James Bigler wrote:
So, I had a dynamic library with the following:
SET_TARGET_PROPERTIES(narfencode
PROPERTIES BUILD_WITH_INSTALL_RPATH OFF
INSTALL_NAME_DIR "@executable_path"
)
When I compile it I get this:
/usr/bin/c++ -dynamiclib -headerpad_max_install_names -o
libnarfencode.dylib -install_name /Users/bigler/cibc/
cpack_install/ opt/libnarfencode.dylib "CMakeFiles/narfencode.dir/
encode.o"
Note that the -install_name is the local build directory. This
works well for when I run the binary out of the build directory,
but if I run "make install" it doesn't relink the library with the
*installed* -install_name.
I believe it should be relinking the library during installation
to match where it will be after it's installed.
Note that if I set it to ON, it works for the installed version
(and may not work for the build tree version).
Here is what works for us:
if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
# No rpath on Darwin. Setting it will only cause trouble.
else(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
option(USE_RPATH "Use -rpath when linking libraries, executables"
ON)
endif(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
if(USE_RPATH)
set_target_properties(
plplot${LIB_TAG}
PROPERTIES
SOVERSION ${plplot_SOVERSION}
VERSION ${plplot_VERSION}
INSTALL_RPATH "${LIB_INSTALL_RPATH}"
INSTALL_NAME_DIR "${LIB_DIR}"
)
else(USE_RPATH)
set_target_properties(
plplot${LIB_TAG}
PROPERTIES
SOVERSION ${plplot_SOVERSION}
VERSION ${plplot_VERSION}
INSTALL_NAME_DIR "${LIB_DIR}"
)
endif(USE_RPATH)
For completeness I left in the SOVERSION and VERSION properties we
set for
the PLplot principal library, but the only difference between the two
alternatives is INSTALL_RPATH "${LIB_INSTALL_RPATH}"
...
I hear from PLplot OS X users that the above CMake logic also works
well on
that platform both for the build tree (where I assume CMake
automatically
does not use rpath for the Darwin case) and install tree (where
because
of the above logic CMake does not use rpath for the Darwin case).
This would work if one had the exact path the library would be in
while compiling. Unfortunately, there needs a flexible mechanism to
install the binaries in different places.
Macs provide a mechanism to have relative rpaths via @executable_path
and @loader_path. This provides a mechanism to install libraries in
a path relative to where the binary will be. This is how Application
Bundles work.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/
DynamicLibraries/Articles/DynamicLibraryDesignGuidelines.html#//
apple_ref/doc/uid/TP40002013-SW21
I guess my other option is to build the libraries directly into the
framework, so that the build tree mirrors the structure of how it
will be installed.
Thanks,
James
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
