If you do release and debug builds with Xcode for frameworks, Xcode will
create completely separate frameworks for each configuration (e.g.
Release and Debug). This is how CMake supports different configurations
There is an additional mechanism how this can be done. In the
configuration dialog "Build variants" can be created, the default
variant is "normal". When adding an additional name to this list, the
library will be built in an additional variant and the name will be
appended to the library name. E.g. if you add "profile" to the list,
additionally to the library "foolib" now also "foolib_profile" will be
created within the same framework. To get different settings/compiler
flags/etc. for this version, Xcode variables have to be defined for this
build variant. They have the same name as the normal Xcode variables,
but have again the name appended:
When building something which links to that framework, the normal name
is used when building. When that application starts, by default it will
load the normal variant. If the developer wants to use the "profile"
variant, he has to set the DYLD_IMAGE_SUFFIX environment variable
accordingly. So if DYLD_IMAGE_SUFFIX is set to "_profile", the
application will get "foolib_profile". The same mechanism is used in
the original OSX frameworks, there are "debug" variants of the
frameworks available. This means if DYLD_IMAGE_SUFFIX is set to
"_debug", an application will get the debug versions of the OS X libs
and the debug version of "foolib" (if it exists). If the developer wants
only debug versions of his own libs then he has to use a different
Versions in frameworks
Frameworks have version directories, usually version "A" with the
symbolic link "Current" pointing to it. When an application is linked to
a framework using "-framework Foo", then the link "Current" is used but
the link destination is recorded in the application, so that when the
application starts it doesn't matter to which version "Current" points.
If there are two versions, "A" and "B" in a framework, and "Current"
points to B, but a developer wants to build his application against
version "A", the dylib_file option has to be used for
Alternatively the library inside the framework could be used directly:
gcc -o Prog3 Foo.framework/Versions/A/Foo
dylib_compatibility_version and dylib_current_version
dylib_current_version is the current version of a dyld library
(equivalent to the full versioned name of a so library).
dylib_compatibility_version is the version to which the current
version is compatible. I.e. the current version 1.2.3 could be
compatible down to version 1.0.0 (or any other version before it, e.g.
0.5.3). This is somewhat similar to the SOVERSION of an so library,
where a different SO version means a really different version of the
library, but with the two dyld versions this can be used much more fine
grained. So if an executable is linked against a dyld library with
compatibility version 1.0.0, but when executing the linker finds only a
current version 0.9.0 the app will not start.
This page was initially populated by conversion from its original location in another wiki.