[CMake] install name for fortran dylibs on mac
clinton at elemtech.com
clinton at elemtech.com
Sat May 3 10:17:43 EDT 2014
----- Original Message -----
> Hi,
> After much head scratching and googling, I found a way to get the dynamic
> library built in a project of mine to have the correct install name, so long
> as `DESTDIR=/some/path` is NOT specified upon install. Basically I want to
> export the library from both the build tree and the install tree so that
> client projects can choose whether or not they want to install the project
> (which provides static and dynamic libraries) or just link against it from
> the build tree. (If they choose to link against the dylib in the build tree
> the this could cause them issues down the road, for example if they `make
> clean`, but the implications of linking against a dylib in the build tree
> seem fairly obvious.) Right now I am doing this by using the
> CMAKE_INSTALL_NAME_DIR variable. I just have the full path to the install
> directory in that variable. This way when I build it CMake is smart enough
> to use the build tree as the install name, then change it during the
> install. However, it would be nice to be able to support DESTDIR.
> Is there a way to do this? Or a better way than I am currently doing it?
> Should I be building a framework or bundle on mac… the using
> `fixup_bundle()` or the like… This seems like overkill for this library, but
> maybe it’s the only portable easy way to do this. Or maybe I could call
> install_name_tool after the install to ensure that the dylib knows the full
> absolute path to itself?
I would suggest the following as a better way:
Use at least CMake 2.8.12 and in your library project add this:
set(CMAKE_MACOSX_RPATH 1)
The install name will have @rpath, and the dylib is relieved of the burden of knowing the absolute path to itself, in both the build tree and install tree. The burden is shifted to the client knowing the location of the library it is linking against, which it already knows anyway, but there is another linker flag (-rpath) specifying that path. Clients should also use CMake 2.8.12 or newer.
For more details:
http://www.kitware.com/blog/home/post/510
Clint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140503/a87ea761/attachment-0001.html>
More information about the CMake
mailing list