[CMake] INSTALL_NAME_DIR on MacOSX
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). James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL_NAME_DIR on MacOSX
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 only have access to Linux, and the above works great there both for the
build tree (where CMake does all the required rpath stuff automatically so
that build-tree tests work without having to set LD_LIBRARY_PATH). For
Linux, the above also works great for the install tree where rpath is set
appropriately unless the user specifically wants to turn it off with
-DUSE_RPATH=OFF. (This no-rpath option for the install tree is useful for
the case of a system install location where rpath is not necessary, and
normally not desired as well).
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).
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL_NAME_DIR on MacOSX
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
Re: [CMake] INSTALL_NAME_DIR on MacOSX
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
Re: [CMake] INSTALL_NAME_DIR on MacOSX
On 2007-10-24 13:54-0600 James Bigler wrote:
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.
Sorry, I should have stated that the CMake variable LIB_DIR above is
the configured install location for the libraries.
Unfortunately, there needs a flexible mechanism to install the
binaries in different places.
Well, the above is flexible in the sense that the user has complete control
over the install location for the libraries at cmake time. I haven't tried
multiple install locations for the same build tree, but I suspect those
would not work and you would need different build trees (or complete removal
of the original build tree) for different install locations. Thus, this
mechanism might not be as flexible as you desire. OTOH, if you have code
that depends on the install location (e.g., PLplot has some installed map
files and font files it needs access to), the normal/obvious thing to do is
to configure that code with CMake. So the above mechanism for choosing
install locations is all that is available to us in the PLplot case, and you
might have similar constraints.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
