Re: Framework versions and linkage
Re: Framework versions and linkage
On 20 Sep 2009, at 11:07, Ken Thomases wrote:
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.)
Thanks for the confirmation Ken. I get the purpose of the symlink now.
The comment in the original made me think that there was an extra
level of linkage indirection occurring at runtime.
Cheers,
Ken
Jonathan Mitchell
Developer
http://www.mugginsoft.com
_______________________________________________
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