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: Peter O'Gorman <email@hidden>
- Date: Mon, 25 Feb 2008 09:57:14 -0600
David Elliott wrote:
> Hi Peter,
Hi David,
>> 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.
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.
>
> Even if you never use the new libiconv functions, you still can't run if
> you linked to libiconv. On a Linux system, this would not be the case.
> The soname would be the same (e.g. libiconv.so.X) but the versioning
> info would be incremented appropriately. On Darwin the appropriate
> thing to do is leave the full name the same (e.g.
> /usr/lib/libiconv.X.dylib) and increment the current version but not the
> compatibility version.
No, I have to disagree. If someone uses the new symbols in the new
libiconv then their application will not work with the older libiconv,
that is what the whole compatibility_version is about. Older
applications which use only the functions in the older library will
continue to work with the new library, but newer applications using
functions only present in the new library will not work with the old.
This is how it should be. When interfaces are removed then the
install_name (soname) of the library should change and the
compatibility_version etc start at the beginning again.
If you have complaints or suggestions for the libtool versioning scheme
on darwin, please bring them up on email@hidden, and I will answer
them there. I do not think that the versioning scheme can now change,
however, as it would introduce binary compatibility issues.
>
> What would happen in both cases on Linux and Darwin is that the app will
> crash when trying to bind missing symbols if and only if it actually
> uses the newer symbols.
I do not think that crashing like that is the desired behavior, if that
were desired then compatibility_version would be unnecessary.
>>
> 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.
Peter
--
Peter O'Gorman
http://pogma.com
_______________________________________________
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