[cmake-developers] SONAME on APPLE?

[Brad King]

On 07/09/2012 12:17 PM, Stephen Kelly wrote:
> It seems that on APPLE, otool -D <the_lib> will output the "shared library 
> id name". I don't know for certain that it is the same thing (I know very 
> little about APPLE), but CMake seems to set that based on the name of the 
> library, the SOVERSION property, and the file suffix. So far it seems 
> similar to the SONAME reported by objdump on linux.

They are basically the same thing.  The shared library id or "install name"
is copied at link time into the dependents.  The dynamic linker uses the
name to search for the library at runtime.

> CMake seems to populate the "shared library id name" (Let's call it SONAME 
> for now, even on APPLE) with a full path when the library is in the build 
> directory ("/Users/kdab/dev/cmake/build/libcmakeqt.5.dylib"), and without 
> the path when installed (Only "libcmakeqt.5.dylib"). 
> 
> I don't know if that is configurable.

See the INSTALL_NAME_DIR target property.

> I didn't find any way to create 'frameworks' with CMake, so I don't know if 
> there is even the concept of a SONAME when creating a 'framework' on APPLE.

See the FRAMEWORK target property.

> CMake seems to use this information to compute the link line, so it would 
> seem advantagous that I set it correctly on relevant platforms. Can anyone 
> add clarity to anything I wrote?

IIRC the main reason CMake wants the soname for imported targets
(hence IMPORTED_SONAME) is so that target->GetSOName returns the
correct value.  This is used in Source/cmComputeLinkInformation.cxx
at least to check for conflicts in the library search path order.
I don't remember if there are other uses.

> Should I set the IMPORTED_SONAME to these 
> full paths to the installation location on APPLE? Wouldn't that make the 
> frameworks non-relocatable, or is that a bug in Qt anyway?

Ideally the IMPORTED_SONAME should match the shared library id of
the actual library file.  That's what CMake wants to know.

-Brad