Re: Using weak linking and other techniques with non-Apple libs
Re: Using weak linking and other techniques with non-Apple libs
- Subject: Re: Using weak linking and other techniques with non-Apple libs
- From: David Elliott <email@hidden>
- Date: Mon, 25 Feb 2008 22:28:43 -0500
Hi Peter,
On Feb 25, 2008, at 10:57 AM, Peter O'Gorman wrote:
David Elliott wrote:
I think you misunderstood me. This is exactly the case now. You
cannot
build against libiconv from Leopard and run on anything other than
Leopard because dyld will kill your program immediately at startup
because your program says it requires 7.0.0 and Tiger only has 5.0.0.
No, I understood, but now that Apple have shipped Leopard with
libiconv
with a compatibility version of 7.0.0, they can not reduce it because
any currently shipping binaries that were linked on Leopard will stop
working on leopard. Not a good plan.
Actually they could reduce it to compat 5.0.0, current 7.0.0 and no
existing apps would break. However, I do see your other point. See
below.
If you require that your application run on Tiger and Leopard, you can
always use the 10.4 SDK. But, if Apple had spent the time and effort
to
inspect all their open source projects and modify the headers and
libraries then you would be able to use 10.5 features on 10.5 and put
-mmacosx_version_min=10.4 in the compiler and linker flags to ensure
that the new interfaces were marked weak. Apple has not done that for
10.5, with an enhancement request they may do it for 10.6.
The problem is that using an older SDK is not an option when you must
be able to link to newer versions of other libraries.
[big snip]
Right. Like I said, just having accurate library versioning (e.g.
compatibility 5.0.0 current 7.0.0) would be enough. I can figure out
myself which functions are present in which OS X releases.
That is inaccurate versioning, in my opinion. Applications linked to
the
new library may not be compatible with the old.
You're absolutely right. I refreshed my memory:
http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html
What happens is that you see libSystem and most of the other Apple-
developed libraries completely breaking this convention because they
have deferred compatibility checking to a higher level.
Indeed it is true that when you add an interface you must increment
the compatibility version because some random person using the library
in the normal way will expect those functions to exist. And therein
lies the failing of dyld's versioning scheme.
If I never use any of the added symbols, and I know I do not use them
then there ought to be a way I can specify through some ld options
that I can use an older version. Or better still perhaps I can
specify an option that I'd like ld to scan for the symbols I actually
use and set the compatibility version to the lowest possible
containing all of those symbols.
For that to happen the dylib would of course need to actually have
some amount of per-symbol versioning which dylibs do not at this time
have.
That's okay though as it makes me feel a lot better about my scheme to
simply grab /usr/lib/libiconv.dylib and bump its compatibility version
down to 5.0.0. Its current version can stay as is to document that it
really was linked against 7.0.0. I then need only place the hacked
libiconv.dylib in one of the -L paths and all is well. To handle the
added symbols I simply need to make sure to use the weak-linking
features, if I even need those symbols at all.
Thanks for taking the time to get my mind right on this again. I'll
have to add per-symbol versioning to my growing list of dreams.
Theoretically, it would be possible to implement by only changing the
static link editor to record more information when making a library
and to use that information when linking to it. Dyld need not even
consider it.
-Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden