For developers‎ > ‎Using MacPorts‎ > ‎

Purity checking

This page is about checking the "purity" (read: absence of links to ApplicationServices, CoreServices and other proprietary, closed-source frameworks and libraries).

About "purity"

Since the proprietary, closed-source frameworks and libraries that are part of Mac OS X but not Darwin, we must ensure that none of the binaries generated through the MacPorts project link to any of them.

What additionally complicates the matter is that links are "inherited" in the Darwin linker system. Say, liba links to ApplicationServices by mistake, libb links to liba, and libc links to libb. In this case, even libc now has the "wrong" link to ApplicationServices, even though libc itself wouldn't need it.

Typically ApplicationServices will not show up in, but configure will put it into the autogenerated Makefile in these cases.

So it is really crucial to check that no unneccessary links are introduced into the system, as they propagate all the way up through the stack.


The script at the bottom of this page will help you checking the "purity" of a given RPM package (todo: include this in MacPorts before/after building the RPM...).
Also, take a look at Visualize dependencies in MacPorts page if you want to check (and have an overview) of the "purity" of all dependencies (installed ports) for a given portname.

Alternatively, you can use something like this to see impurities as they happen during the build process:

sh-3.2# port clean cairo ---> Cleaning cairo sh-3.2# port -v -d build cairo +puredarwin 2>&1 | grep Services checking ApplicationServices/ApplicationServices.h usability... yes checking ApplicationServices/ApplicationServices.h presence... yes checking for ApplicationServices/ApplicationServices.h... yes

Another check is 

grep -R Services /opt/local/lib/pkgconfig/

otool -L /opt/local/lib/*.dylib | grep Services

Which should not return anything like ApplicationServices and the like.


The following are proprietary, closed-source frameworks and libraries that we must not link to if we want to deploy some binary packages generated through MacPorts to PureDarwin.
  • AppKit
  • ApplicationServices
  • Carbon
  • Cocoa
  • CoreFoundation (if CF-Lite is insufficient, which needs to be tested manually)
  • CoreServices
  • Symbolication
  • ...


Some results of the example shown above
  • Terminal links to ApplicationServices
  • Thunar links to ApplicationServices and CoreServices
  • Xft2 links to ApplicationServices
  • cairo links to ApplicationServices and CoreServices
  • exo links to ApplicationServices
  • fontconfig links to ApplicationServices
  • glib2 links to Carbon
  • gettext links to CoreFoundation
  • libglade2 links to ApplicationServices
  • libxfcegui4 links to ApplicationServices and CoreServices
  • mousepad links to ApplicationServices
  • orage links to ApplicationServices
  • pango links to AppKit, ApplicationServices, Carbon, Cocoa, CoreFoundation, Foundation
  • popt links to CoreFoundation
  • python25 links to AppKit, ApplicationServices, Carbon, CoreFoundation, CoreServices, Foundation, QuickTime
  • xfdesktop links to ApplicationServices, CoreServices
  • xfprint links to ApplicationServices, CoreFoundation, CoreServices
  • xfwm4 links to ApplicationServices, CoreServices
Subpages (1): Reinheitsgebot
Oct 12, 2008, 2:19 PM