Re: Framework versions and linkage
Re: Framework versions and linkage
- Subject: Re: Framework versions and linkage
- From: Ken Thomases <email@hidden>
- Date: Sun, 20 Sep 2009 05:07:15 -0500
On Sep 19, 2009, at 2:40 PM, email@hidden wrote:
I thought the whole reason for having the multiple library symlinks
in /usr/lib was so that binaries could link against the generic
library name and have it resolve to the current version at runtime
(as is done with the library symlinks inside frameworks.)
Looking at my app with otool -L I can see that it explicitly
references the major version of various frameworks, say:
/System/Library/Frameworks/Foundation.framework/Versions/C/
Foundation (compatibility version 300.0.0, current version 751.0.0)
To me it seems that this code must link against version C,
regardless of whether versions D..Z exist in the bundle or not.
C is not at its original compatible version number but at 751,
which is nonetheless deemed to have retained a compatible interface
with version 300.
This implies that the linkage is not really variable. The app has to
find a compatible version of the major version C at the given path.
If not, it perishes.
If D exists our app can only link against it after recompilation.
Is this correct or does a horrible confusion reign?
The above is correct. A change in framework version from C to D is
done precisely because of a non-backward compatible change. That is,
version D is not suitable for a program linked against C; if it were,
then it would still be version C. Conversely, so long as new releases
of a framework maintain the same version (C in this example), that
means they remain backward compatible.
Regarding the original quote: the reason for the symlink is so that
projects and makefiles don't have to specify which version for the
link commands. They just link against the generic name, which
resolves to a specific version, as appropriate for the build system
(or SDK). The specific version's install name is what gets baked into
the executable. (The actual file name doesn't matter, neither the
path to the symlink nor the path after the symlink is resolved. Only
the install name recorded in the library ultimately referenced matters.)
Cheers,
Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden