On Oct 24, 2007, at 3:54 PM, James Bigler wrote:
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
I use a custom shell script that uses "install_name_tool" to adjust
the install_path after compilation. For me this seems to be the least
painful way to accomplish this. The support in CMake just does not
work how I expect it to work (ie. like xcode). In that shell script
(which gets configured by cmake) I also copy the library into the
Application bundle and also set the install_names correctly in the
built application. All kinda "kludgeish" to me.. but does work. I end
up with a self contained Application that is portable across
different macs.
Just my 2 cents. If you want copies of the shell scripts they are at:
http://titanium.imts.us/viewvc/Task_7/MXADataModel/Resources/
PackageMXALibsForOSXAppBundle.sh.in
--
Mike Jackson Senior Research Engineer
Innovative Management & Technology Services
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake