Nat!'s Web Journal

foo.m:17: warning: 'NSLookupSymbolInImage' is deprecated 
(declared at /Developer/SDKs/MacOSX10.5.sdk/usr/include/mach-o/dyld.h:182)

/*
 * The following dyld API's are deprecated as of Mac OS X 10.5.  They are either  
 * no longer necessary or are superceeded by dlopen and friends in .
 * dlopen/dlsym/dlclose have been available since Mac OS X 10.3 and work with 
 * dylibs and bundles.  
 *
 *    NSAddImage                           -> dlopen
 *    NSLookupSymbolInImage                -> dlsym
 *    NSCreateObjectFileImageFromFile      -> dlopen
 *    NSDestroyObjectFileImage             -> dlclose
 *    NSLinkModule                         -> not needed when dlopen used
 *    NSUnLinkModule                       -> not needed when dlclose used
 *    NSLookupSymbolInModule               -> dlsym
 *    _dyld_image_containing_address       -> dladdr
 *    NSLinkEditError                      -> dlerror
 *
 */

extern NSSymbol NSLookupSymbolInModule(NSModule module, const char* symbolName)
AVAILABLE_MAC_OS_X_VERSION_10_1_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_5;

What bothers me, that one of the ideas behind Foundation is, that it should isolate me from the OS layer and abstract to a common denominator, that remains stable. Yet here, the Foundation functions are deprecated and I am suposed to use dyld directly, although Foundation still could (and probably does) do the work using dyld.

I don't get this.

Here's the unix command I used to get the statistics. I am collecting recursive all the header files inside an SDK directory, unique them by filename (which is a bug, but better than not doing it) and check for the AVAILABLE...BUT..DEPRECATED string. Then I massage the output a little, so I can easily put it in a table:

( for i in `find /Developer/SDKs/MacOSX10.4u.sdk/ -name "*.h" -print` ; do file=`basename $i`; echo "$file" "$i"; done | awk '{ files[ $1] = $2 } END { for ( x in files) print files[ x] }' | xargs egrep -H "AVAILABLE_MAC_OS_X_VERSION_10_._AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_." ) | egrep -v "#define|#ifdef|#ifndef|\ \*\ .*AVA" | sed 's/.*\(AVAILABLE_.*_10_.\).*/\1/' | sort | uniq -c | sed 's/AVAILABLE_MAC_OS_X_VERSION_10_\(.*\)_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_\(.*\)/\1 \2/'

which exposes that the JavaVM.framework is apparently broken in the 10.6 SDK, but who uses Java anyway ;)
egrep: /Developer/SDKs/MacOSX10.6.sdk//System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/jvmdi.h: No such file or directory
egrep: /Developer/SDKs/MacOSX10.6.sdk//System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/jvmpi.h: No such file or directory

Anway here are the results:

How to read this chart. On the left side is the released version. The bars show the number of symbols deprecated of previous OS X versions. So for example the top entry 10.1, shows that it deprecates less than 10 function from 10.0. Then 10.3 deprecates a few symbols from 10.0 and 10.2 and so on. Further interpretation of the data is left to the reader.

What is kind of interesting is to compare the raw numbers for the various SDKs. I checked 10.4.u.sdk, 10.5.sdk and 10.6.sdk. The horizontal axis has the version that deprecates, the vertical axis has the version that suffers deprecation:

• 10.4u.sdk seems to be broken, as it has deprecations from 10.5 already
• since deprecations seem to disappear over time, this could mean, that either symbols were really removed, or that some symbols were wrongly deprecated

The methodology used here isn't perfect, because I am not checking all headers. But I hate scrapping the whole entry ;)

#include <stdio.h>

main()
{
   int  x;

   // \\\\\\\\\\\  ///////////// 
   // ||    POWERFUL MAGIC    ||
   // //////////   \\\\\\\\\\\\\
   x = __powerful_magic__( 1848);
   printf( "%d\n", x);

   return( 0);
}