[Pythonmac-SIG] Building compatible dependencies

[Ned Deily]

In article 
<CAH6Pt5rZ0hn3BXLn-mEM+nAGyydV0gXtf6EY6T1B3+e=xNNryw at mail.gmail.com>,
> On Wed, Jun 11, 2014 at 4:58 PM, Chris Barker <chris.barker at noaa.gov> wrote:
> > I know it'a at least theoretically possible to build libs under 10.9 that
> > will work on 10.6 -- specifically compatible with the python.org python
> > binaries.
> >
> > But I"m having trouble finding documentation of what flags you need.
> >
> > MACOSX_DEPLOYMENT_TARGET=10.6
> >
> > should be required -- but anything else?
> >
> > personally, I've solved this by building on the oldest machine I want to
> > support, but that's not always possible anymore.
> 
> Have you run into any problems using the deployment target = 10.6?
> 
> I haven't with wheels at least - I'm building on 10.9 and testing on 10.6

It all depends on what you are building.  I assume you're talking about 
non-Python packages here.  Many C modules won't be a problem but some 
will if they use OS-supplied APIs that have changed or been added 
between the deployment target version of OS X and the build systems's 
target.  If you need to support the full range of systems, your safest 
best remains to build on deployment target system.  Otherwise, until 
proven otherwise for the particular package, you should be using the SDK 
for the deployment target version and hope that the build system 
(Makefile, whatever) for the package builds correctly with an SDK.  In 
many cases it will because Apple cleverly hid much of the SDK and 
universal arch complexity under the covers in the compiler driver 
wrappers for cc/gcc/clang.  Basically when you use an SDK, the Apple 
compiler driver automatically prepends the SDK path to all "system" 
files, those beginning with /System/Library, /Library, and /usr, so that 
they are picked up from the SDK directory rather than from the running 
system.   But, if the package's build process does something clever, 
like making its own decisions about where to look for libs or include 
files that does not take the SDK path into account, you can end up with 
subtle errors, where the package build is basing decisions on the build 
system's installed include files (i.e. the 10.9 version) whereas the 
compiler is actually building with the SDK version (i.e. 10.6) of the 
file.  (Builds of Python itself have run into this problem in the past.)

If you want to fully support universal architectures (Intel-32 and 
Intel-64 for the python.org 64-bit/32-bit installers), you also need to 
build universal libraries.  Adding -arch i386 and -arch x86_64 will 
usually work but not always (OpenSSL is an example of one where it 
doesn't).  If the package build makes arch dependent decisions at 
configure time (or the equivalent) or arch-dependent values are in 
generated include files or something similar, the safest approach is to 
build each arch separately and then use lipo to combine the separate 
archs into universal file(s) to be installed.  Fortunately, most popular 
libs either now natively support universal builds or someone has figured 
out how to do it.  The build recipes in MacPorts or homebrew can be of 
help here.

On the most recent versions of OS X, particularly on 10.9, there is 
better support from the command line tools for building with SDKs by 
setting the SDKROOT and DEVELOPER_DIR environment variables.  See the 
man page for xcrun (man 1 xcrun) for more details.

Also, note that when building C extension modules via Distutils in 
current Pythons from python.org, the SDK used to build Python is looked 
for in its original path (for example, /Developer/SDKs/MacOSX10.6.sdk) 
and, if not found there, the ext module build proceeds without an SDK, 
using the headers and libs of the installed command line tools.  Most of 
the time that is fine if you are building something to be used solely on 
the build system's OS level and probably for later systems.

-- 
 Ned Deily,
 nad at acm.org