Using weak linking and other techniques with non-Apple libs
Using weak linking and other techniques with non-Apple libs
- Subject: Using weak linking and other techniques with non-Apple libs
- From: David Elliott <email@hidden>
- Date: Fri, 22 Feb 2008 11:53:46 -0500
Hi,
I'm the author of wxCocoa and also do enhancements on the general
wxWidgets codebase now and again. One goal of the project is that the
library should be able to build with the latest headers (e.g. 10.5)
and still be able to be run on older versions. For wxMac and wxCocoa
you basically have to build with the latest headers to get the most
completely library. But for the base parts of the library, the latest
headers will make things available that aren't on prior releases.
One thing I've recently discovered is that it's possible to redeclare
a function with the weak linking attribute. For instance, backtrace
only exists in the Darwin 9 (10.5) libSystem. Thus I can do something
like this:
#include <execinfo.h>
#ifdef __APPLE__
#include <AvailabilityMacros.h>
int backtrace(void**,int) AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER;
#endif
That then allows me to check &backtrace != NULL and see if backtrace
functionality is available. It's only really necessary to weak-link
one of the functions since the rest will continue to be lazy bound.
So long as they never get called (by virtue of having checked the
address of backtrace) the app will work on pre-Leopard without crashing.
I haven't gone through and really applied this everywhere but the
technique looks sound. It's not quite complete though. For instance,
libiconv exists from 10.3 onward but the 10.5 library has
current_version and compatibility_version both set to 7.0.0 whereas
10.3 and 10.4 used 5.0.0.
In lieu of Apple changing the library to use compatibility version
5.0.0 current version 7.0.0 (which would probably be the better thing
to do) is there some way I can do this myself? One hack I have tried
is to simply grab the /usr/lib/libiconv from the 10.4 SDK and drop it
in one of the directories on the linker's -L path. This seems to work
without problem now but I'm thinking that if we were to ever use new
symbols present only in the newer library versions, even if weak-
linking to them similar to the above, we'd be in trouble.
It's also sort of a pain to have to find an copy the old version. So
I was wondering if there is some equivalent to install_name_tool that
I can use to change the versioning info. For instance, grab
libiconv.dylib from either the SDK being used to build (or the
system), modify the compatibility version number, and place the
modified copy into a directory on the linker's -L path.
As far as I know, it would be rather trivial to write such a tool and
if there isn't one I'll do it. But I figured I'd ask before embarking
on that.
-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